Yes, anonymity is still achievable, and more backup options are always better.
The strongest point I'd like to make is: retain the password and all unencrypted data within the browser. If you're willing to work on a system to do this, I'm willing to contribute to the open source ajax part of the solution.
I'm researching and working on something along those lines but there are still issues with trying to do encryption within the browser. Not to mention the backend problem.
I would suggest that maybe we can work together on a common browser front end, that would work with different backend. This way, we always have the option to switch between different backend solutions if one proves to be better or worse.
What are the issues you're finding? I know there are open source javascript encryption libraries, but I haven't researched how well they perform or are vetted.
Given that you can interact with the user, accept the password, etc entirely within the browser, and assuming that a suitable and trusted existing encryption library can be used, the rest is just standard ajax between js/server. A lot of work of course, but no new ground.
I think you're right that we should work on the common browser front end and treat the JS code as inherently separate from the backend code (we'd define an API I suppose). I would prefer the JS to be hosted separate from the server operator, but I would still accept a one host system, since its still a big step forward. But as long the browser front end is treated separately, its the right road map.