Diffie-Hellman based password challenge response scheme A very commonly used (examples: HTTP digest auth/CHAP/Kerberos) authentication scheme is something that looks like:

Setup.


Client and server both know a password $p$.


Authentication.


Server sends a random challenge $\alpha$.
Client computes $r = \text{KDF}(p || \alpha)$ and sends $r$ to the server.
Server computes $r' = \text{KDF}(p || \alpha)$ and checks $r' \overset{?}{=} r$.


This scheme is also described in other questions (example).
Now this scheme has the disadvantage that the server needs to know the plaintext password. Could we make a public-key-based scheme for challenge response authentication?

For example, we could use elliptic curve arithmetic:

Setup.


Client has a secret password $p$ (with reasonable entropy) and from this derives a key  $k$ using a hash function.
The client computes $[k]P = Q_k$ and the server will store this value as the user's public key.


Authentication.


Server sends a random challenge $Q_\alpha = [\alpha]P$.
Client computes $Q_s = [k]Q_\alpha$ and sends $Q_s$ to the server.
The server computes $Q_s' = [\alpha]Q_k$ and checks $Q_s' \overset{?}{=} Q_s$.


Does this scheme work? Why would most systems use HMAC-based scheme instead?
First off, what you are trying to construct here is called an augmented or asymmetric password-based key exchange (aPAKE). As for your concrete construction:


  Does this scheme work?


Yes, it will be functionally correct.

Does it actually achieve the security guarantees of an aPAKE scheme? No, an attacker can look at the transcript, see $Q_s=[k]Q_a$ and knows both $Q_s$ and $Q_a$ and thus can just off-line brute-force the password.

The first (symmetric) scheme you mentioned suffers from the same problem.


  Could we make a public-key-based scheme for challenge response
  authentication?


This is what aPAKE schemes do, the most notable protocols are:


the Secure Remote Password Protocol (SRP), mostly because it was first to be standardized in RFC 2945.
OPAQUE which is the current state-of-the-art when it comes to (simple) aPAKEs.
If you also want to assume an auxilliary 2nd device for the user, OpTFA is the state-of-the-art.
If the user "only" has a device capable of running an (EC)DH key agreement (like a smartcard), then PTR-PAKE is the best you can get.


Example implementations (in C) of OPAQUE and PTR-PAKE can be found in libsphinx.