Go read http://en.wikipedia.org/wiki/Digest_access_authentication and become informed on how you can do hashing on the client's browser and actually gain something in the way of security.
I did in fact read the article, and I do now agree that you only need to send MD5(username:realm:password) to the remote server to do the authentication.
The problem that I do see is that it is trivial for a MITM to either intercept the transaction and force the client into a less secure mode (ie. basic auth), and then read in the password, or else just reuse the auth credentials for another transaction.
I would recommend that you look at http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol and the concept of a "zero knowledge password proof" which seems to be the concept you were looking for.
Incidentally your snideness is not appreciated. Generally something doesn't get to be a widely implemented RFC without the obvious questions having been asked and answered.
But if you want such a ridiculous requirement, you can have JavaScript on the signup form that computes the hash on the client and sends it to the server. That form still needs to go over a secure channel (eg https) because the information sent, while not including the plain text password, is sufficient information for a sufficiently motivated attacker to get access.
Your reply, coming where it did in the thread, gave the impression you thought digest auth somehow avoided ever sending a plaintext password to the server.