Handling the key pair and licensing can absolutely be done with a zero-knowledge protocol, like yours or similar to it. Actually I think it can be made even more simple, by simply generating the key pair locally and only upload the encrypted private key, never generating or encrypting it on the server.
The main problem you have already pointed this out – the online password manager. It gets so much more complicated and risky if the data is kept locally, and it completely (well, almost) removes the use of it with a simple web browser – which actually is a very important use case for it! Downloading and uploading updates is of course possible, but inefficient after some time, and a little risky.
Another problem, but it can be handled, is the invitation process. Where Alice invites Bob to a document, and Bob does not have an account. What we do now, is we generate the key on the server, and keep it encrypted with a machine key utnil Bob sets his own password, at which point the key is re-encrypted with that password. Of course, that can be tweaked to only use it as a temporary key until Bob sets his password at which point we update the key pair on the server with a locally generated one. This would minimize the exposure, even if not remove it completely.
Of course – if you don’t use the password manager or ever sign in on the web, we don’t need to see the password.
However, it does get a little more complicated for users to understand what’s going on, and for us to support them.
We have relatively few users actually requiring zero-knowledge at this time.
Concerning fingerprint support etc, it requires a little bit of extra consideration. Please read my blog post on the subject for a longer discussion: https://www.axcrypt.net/blog/encryption-and-biometrics/ .
Further comments welcome. We will be developing along these lines, but we some other priorities currently – most notably Mac OS X support which is coming soon!