This follows on from How do I produce a stream of secure random numbers from AES-Counter mode?
Consider then the generator:-
$$ \operatorname{AES_{k1}}(n) \oplus \operatorname{AES_{k2}}(n) $$
where $ k1 \ne k2 $, and $n$ is the single counter variable. And we take care to ensure that there is no relationship between $k1$ and $k2$. If this really does create a pseudo random function, will the birthday boundary for AES-CTR output be overcome?
Yes. The number of $n$-bit blocks you can encrypt with this construction is proportional to $2^n$ instead of just $2^{n/2}$. So for AES this shouldn't be a problem because you can't process anything near $2^{128}$ blocks.
A secure stream cipher can be constructed from a PRF using something similar to AES-CTR.
AES is more accurately described as a PRP than a PRF, but this distinction is unimportant if the number of queries an attacker is allowed to make under a given key is much much less than $2^{64}$.
(See PRF switching lemma. If the number of queries the attacker can make is much less than $2^{n/2}$, then it is safe to substitute an $n$-bit PRP for a PRF. This is where AES-CTR's limit comes from.)
However it has been proven that the XOR of two PRPs is a secure PRF instead for up to $\mathcal{O}(2^n)$ queries. 1 2
Readers should note that this isn't the same as saying that you can use up to precisely $2^n$ blocks. For this reason, I strongly discourage using a block cipher algorithm with smaller blocks (like DES, Simon, or Speck) in this kind of construct. (Or any other mode, I suppose.)