In fact, if you use the first described password authenticated key exchange protocol (Encrypted Key Exchange, by Bellovin and Merrit, in 1992), it is quite clear that you get forward secrecy for free. Roughly put, this is a Diffie-Hellman key exchange with ephemeral keys, whose messages are then symmetrically encrypted, using the shared secret (the password) as key (this symmetric encryption must be such that decrypting with the wrong password still yields syntactically valid DH public keys). Even if an attacker learns the password, all he can do is to recover the inner DH exchange, that used ephemeral keys.
This is in fact a general property for all PAKE. The point of a PAKE is that both parties have only one long-term secret (the password), so everything else is ephemeral; moreover, since that secret has low entropy and is thus in range of exhaustive search (a "dictionary attack"), a strong PAKE must be such that whenever the attacker tries a potential password, he can never know whether he got the right one. This implies, in particular, that even if the password is revealed after the fact, the key exchange itself must remain impregnable. That password being the only non-ephemeral secret, the property of forward secrecy follows.
Or, said in the other direction: if a PAKE protocol is not forward-secure, and obtaining a copy of the shared password allows unraveling the subsequent data encryption, then that mechanism can be used to "test" passwords (run the break-the-encryption attack for each potential password, see if that yields a key which makes sense); in that case, the PAKE protocol does not fulfill its PAKE properties.
To sum up: contrary to what you fear, you will get forward secrecy because you use a PAKE protocol.
(Of course either party can still do something stupid and, for instance, save the secret key resulting from the PAKE into a file, which then breaks forward secrecy.)