Your understanding of this subthread is very different from mine. I'm talking about practical security options for practical websites. In that case you don't care about information that was transiently present in the server for a fraction of a second once, you care about information that has been persistently stored.
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.
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.