How do you break through the chicken and egg problem of not enough users using or not enough browsers supporting this capability?
<input type='password' password-nonce='42'></input>
Browsers that support the password-nonce argument sign as I described. Browsers that don't support it pass through the password and the server performs the ZKPP key generation (this is no worse than the current system of hashing passwords). So servers can implement this immediately without worrying about breaking in non-supporting browsers.
After adoption by a few major sites, browsers can add a warning that the server didn't send a password nonce and the password will be passed to the server so the user has to click "Okay" before it gets submitted. This can be escalated to more severe messages to pressure more sites to comply.
Governments are one such large customer.
Vendors, faced with multiple customers requesting a feature, but with slightly varying specifications, will tend to seek a mutually acceptable spec.
The basic idea is, the server gives a unique nonce with the password form. The user enters their password. On form submit, the browser stretches the key space of the password using a slow hash, then uses the digest to generate an asymmetric key via a referentially transparent algorithm (no random salts). Then the browser prepends the URL (obtained from HTTPS) to the given nonce (to prevent man in the middle attacks). The browser then checks to see if it has seen this nonce before and displays an error if it has (to prevent replay attacks--this forces servers to generate new nonces, although the browser can't force them to verify that the nonce that is signed later is the same one they sent). Finally the browser uses the key to sign the nonce, and sends the signature to the server. The server uses the public key (which was generated in the same way and given to the server at sign-up) to verify that the user has the password.