In theory, this is certainly possible - see this answer about doing the key generation. However, bear in mind that you're going to have to do all of this (hashing and key generation) on the client, which has several undesirable characteristics:
- It's done in JS, which is slower than native code even on modern JIT-compiled engines, and you're doing two different things (password hashing and key pair generation) that are already slow.
- It needs to work exactly the same on each client, and there's no standard JS API for generating a key pair from a given high-entropy seed (or for executing scrypt, for that matter), so you're going to have to supply all the relevant JS code yourself (and ensure it works correctly on all browsers that you support, with polyfills if needed for any library functions) rather than just calling a built-in API.
- Since the hashing is done pre-auth, there's no secure way for the server to supply a salt (that an attacker couldn't get), so you're stuck with salts that might be unique (like username/email address) but are not secret and thus the password hashes can be pre-computed for users of interest. (On the plus side, the extra step of generating a key pair from this hash output provides an additional time cost against brute-forcing attacks).
So, all of this is possible. It is arguably a bit of a hack; there's no inherent browser support for what you're trying (even when it was recommended, the
<keygen> element didn't allow supplying the seed entropy, and the built-in JS crypto API doesn't support that either) and you're kind of re-inventing public-key auth in a slightly weird way (using passwords for client-side key re-derivation, rather than just moving around a client certificate+private key). It doesn't add a lot of security either, as the scripts that do all this hashing and deriving and signing are going to be served by the server so an attacker with access to the server could slightly modify the scripts to steal the passwords/keys anyhow. But it could be done.
EDIT: You tagged this question "web-application" and referred to HTTPS, so I assumed your client was running in a browser. For a thick client, this is much less of an issue; not only do you have a much richer (and usually more performant and better-defined) API to draw upon, it's harder to surreptitiously serve the user maliciously modified code.