Would xoring 2 independant AES CTRs to produce p-rand introduce vulnerabilities? Assuming

$$AES_{k_1}(C_1) \oplus AES_{k_2}(C_2)$$

where AES is used in CTR mode, $C$ is a 128 bit incrementing counter, keys and counters for both transforms are random as well as unique, and the XOR occurs on every 16 byte block.

If I did this, would the XORed output be less secure than the size of state used to seed the generator? Does this method reduce security or introduce vulnerabilities to the random output?
No, this is safe.

In fact, if you show a way of distinguish the stream $AES_{k_1}(C) \oplus AES_{k_2}(C)$ from a random stream with fewer than $2^{64}$ outputs, you have just demonstrated a way of distinguishing AES from a random permutation.

Here is how this works: suppose we are given Oracle assess to a permutation $P$, which might be $AES_{k_1}$ for some unknown key $k_1$, or might be a truly random permutation.

Then, we ask the Oracle for the values $P(C), P(C+1), ..., P(C+n)$, select a random $k_2$, and compute the sequence $P(C)\oplus AES_{k_2}(C), P(C+1)\oplus AES_{k_2}(C+1), ..., P(C+n)\oplus AES_{k_2}(C+n)$.  Then, we run our stream distinguisher on that.

If $P = AES_{k_1}$ for some $k_1$, then this is precisely your stream, and the distinguisher will say "Yes"

If $P$ is a random permutation, well, with fewer than $2^{64}$ outputs, we can treat it as a random function (as collisions are inprobable).   With $P$ as a random function, any value $(C+i)\oplus AES_{k_2}(C+i)$ is a random value; hence the whole stream is a random string, and so the distinguisher will say "No".