To generate an RSA key, you need lots of random bits – more than 4000 for a 4096-bit key (usually more than the key size, since you need to throw away and retest parts if the prime tests fail).
Now, to generate an RSA key, you would love to have the bits being uncorrelated. But if your PRNG has 160 bits of state, you cannot get even 200 uncorrelated entirely random bits out of it. Most of the time, you can get a bit more than the state size safely, but they will obviously not be entirely random, only oh point something random, and not necessarily uncorrelated. The quality of the output of a PRNG is debatable; for example, arc4random(3) is a “stretching RNG” which means that it distributes the entropy in its about 1696 bit of state mostly uniformly across the output (notwithstanding RC4 early keystream bias: the first 3072-plus-some aRC4 output bytes are thrown away), whereas others “exhaust” their full entropy in the first pool-sized read and then are merely pseudo-random (i.e. zero mathematical entropy afterwards); AFAICT the Linux/BSD
/dev/urandom device belongs into this category except that reads cause stirs which increase entropy – more, the more consumers are using the RNG at the same time).
So, this is really a “depends” question. It depends on the security level you want (160 bits of state for an 4096-bit RSA key is really a bit few, but might work for an 1024-bit RSA key, but definitely not for an 1024-bit DSA key) and, to some extent, the properties of the RNG chosen. The general answer is: no, you cannot use a n-bit state RNG to generate an RSA key with n or more bits of size.
「Is there an easier way to crack an RSA key generated using such a PRNG?」 – Yes, but the details may or may not be worth it. For an extreme, see the Debian OpenSSL
RAND_add fiasco, in which the entire key space was, IIRC, 32768 * 2 possible keys, for each key bit size, making it utterly easy to precompute them all (for a few given key bit sizes).