Is there any SRP-like key exchange only using "standard" cryptographic primitives? I am looking into PAKEs (password-authenticated key exchanges), and it seems like SRP (Secure Remote Password) is essentially the de-facto standard.

However, implementing SRP actually requires doing modular arithmetic, and is similar to, say, implementing Diffie-Hellman. That is, you'd have to have constant-time exponentiation algorithms, a fast bignum library, and getting one of any of these subtly wrong and you might have a terrible side-channel attack.

And unlike algorithms like AES or Curve25519, there aren't many crypto libraries that contain a primitive for SRP, so "rolling your own" is often unavoidable anyway.

Are there any PAKEs that instead of using "custom" mathematics like SRP, simply is implemented in terms of more standard primitives, such as "any secure cryptographic hash", "any secure Diffie-Hellman-like exchange", "any secure signature scheme"? It would be a lot more obvious that it's secure - SRP isn't obviously secure at first glance unless you actually follow the reduction to the discrete log problem - and a lot easier to securely implement providing you have secure implementations of the primitives.

For example, I could think of a weak PAKE, where you simply do a Diffie-Hellman key exchange, but both parties attach a MAC to the ephemeral public keys derived from the password. This is obviously secure if the password is strong, but unlike SRP an attacker gains enough information for an offline brute-force attack, and the server has to store the password in plaintext. 

I'm looking for whether there are PAKEs similar to SRP in strength that are as easy as the above weak scheme to intuitively understand and implement in terms of other primitives.
The first protocol for password authenticated key exchange that appeared in the crypto community was the Bellovin-Merritt scheme (see also this survey page 4). This protocol is very simple, and might actually suit your need: is is exactly a Diffie-Hellman key exchange, in which the flows are encrypted with a block cipher (using the common password as the key of the cipher), and where the secret key the players agree on is derived by hashing the Diffie-Hellman tuple. The security of this protocol was analyzed several times, in various models (ideal cipher model or random oracle model, in indistinguishability-based framework or simulation-based framework...). Although it does not enjoy a proof of security in the plain model, you might be satisfied with a protocol proven secure in the random oracle model.

In this case, this scheme seems to exactly fit your requirements: you need "any Diffie-Hellman key exchanged", together with "any (good) hash function" and "any block cipher" that allows you to encrypt the flow with the password. Variations of the Bellovin-Merritt scheme that might make it even simpler are presented in this article (they essentially replace the block cipher by a simple one-time pad, and have two variants, one non-concurrently secure and one concurrently secure).

EDIT: so, after discussing with Ricky Demer, this does not quite work yet. A necessary condition for this to work is that the messages generated by the DHKE - which are group elements - should be indistinguishable from random bit-strings. For DHKE over $\mathbb{Z}^*_p$ for some large prime $p,$ group elements can be naturally mapped to a distribution statistically indistinguishable from bit-strings, and existing implementations might already encode these messages as random-looking bit strings (but this would have to be checked). For more sparse groups such as elliptic curves, I believe such a mapping can be done, but it would be more cumbersome from an implementation point of view. I thank Ricky Demer for pointing this out.

The variants presented in this article do not use a block cipher, which gives rise to dictionary attacks when the encoded element does not look random, but using a kind of multiplicative one-time pad: Alice masks her flow $g^x$ by multiplying it with $M^{\mathsf{pw}}$, where $M$ is a group element and $\mathsf{pw}$ is the password (and Bob plays similarly). Here, you do not have to care about how group elements are represented; however, you must perform an exponentiation (with a small exponent) and a multiplication, hence it does not makes a black-box use of the DHKE key exchange.

EDIT:

So, I discussed today with my PhD advisor, who happens to be the author of quite a number of papers in the PAKE area (in particular this paper which I had mentioned). It confirmed what I had started to think: it does not seem feasible to build a PAKE with a black box access to a DH key exchange and symmetric primitives. Somehow, you have to be at least able to multiply two group elements (hence you must know their structure). I cannot prove that it is infeasible, of course, but that is currently unknown in the scientific community, and not believed to be feasible.