The hash drbg from the drbg package should meet your needs. Deterministic, pure Haskell except the actual hash function.
I was looking at this recently; may I ask why drbg and crypto-api even bother to expose the possibility of CSPRNGs "running out" of entropy? This is not thought to be a concern on any cryptographically sound primitive, and it substantially complicates both the implementation and the user-facing API. The currently selected reseed interval of 2^48 is already large enough that it might as well not be there; it's too large to provide forward secrecy and almost large enough that you'll never hit it.
If you're looking for a more reputable source for this claim, there is a wealth of literature on the current best practices for OS-level CSPRNGs. In particular, both Linux (via the new getrandom(2) API) and the BSDs (via the block device API which has done the right thing for a long time) now have the behavior of waiting for ~256 bits of initial entropy and then providing unlimited random bytes forever without ever blocking or requiring a reseed.
Might I suggest in a future revision of the drbg/crypto-api libraries dropping all mentions of "Either" from the CryptoRandomGen typeclass API, except maybe "newGen"? I think this would make your job a lot easier *and* make the library a lot easier to consume (e.g. via RandT).