How can a block cipher in counter mode be a reasonable PRNG when it's a PRP?
For a random function you'd expect all outputs to be different if you generate fewer than $2^{n/2}$ blocks (birthday problem). Thus PRPs and PRFs are indistinguishable unless you observe about $2^{n/2}$, at which point you'd expect collisions using the PRF but not using the PRP.

For a 128 bit cipher this is a lot of data, so we generally don't care about this. But using a 64 bit cipher, you shouldn't encrypt more than a few gigabytes of data using the same key.


  are there any alternative examples of CSPRNG constructions that generate quality values for arbitrarily large amount of bits?


In principle yes. I think using a variant of CTR mode which uses a secret IV and xors the counter+IV into the output might work. It'd get rid of the trivial "no duplicates" pattern, but it might be distinguishable in other ways.

128 bit blocks should be good enough as a stream cipher/CSPRNG. But if it's a bit too low for your taste (Generating $2^{64}$ blocks is feasible with sufficient effort), you can simply use larger blocks. Typically hash functions (like SHA-2), which want to avoid collisions, use 256 or 512 bit block ciphers.



I've changed the paragraph on wikipedia to


  A secure block cipher can be converted into a CSPRNG by running it in counter mode. This is done by choosing a random key and encrypting a 0, then encrypting a 1, then encrypting a 2, etc. The counter can also be started at an arbitrary number other than zero. Assuming an n-bit block cipher the output can be distinguished from random data after around $2^{n/2}$ blocks since, following the birthday problem, colliding blocks should become likely at that point, whereas a block cipher in CTR mode will never output identical blocks. For 64 bit block ciphers this limits the safe output size to a few gigabytes, with 128 bit blocks the limitation is large enough not to impact typical applications.


I mention the $2^{n/2}$ birthday bound limitation. Removed the part about the period, since it doesn't matter in practice (it's far above both practical output size and safe output size). I also removed the part about keeping key and plaintext (what plaintext? It's a CSRPNG, not a cipher) secret. I'm not really happy with the formulation, so feel free to improve it.