How feasible would it be to generate 300 million public key pairs in 8 hours? Assume there is a hypothetical situation where one would need to generate hundreds of millions of public key pairs of reasonable strength in a limited time. 

What would be required in terms of entropy and how long would it take? Could it be acheived on a single computer? How few computers could one get away with?

If the demand for the public keys was not uniform, how many keys could be generated in a burst?

What effect would different algorithms (RSA, DSA, EC) have?
It is feasible to generate 300 million public key pairs of reasonable strength in 8 hours on a single computer, easily with ECDSA using a single core/thread, and even with DSA using quite a common multi-core computer.

RSA would require many standard computers (baring hardware accelerators for modular exponentiation), assuming all the public keys are made public (see Poncho's answer otherwise, applicable for example if you wanted to generate a single PGP RSA key pair of reasonable security and having the same 32-bit key id as one in 6 pre-existing PGP keys, which is likely achieved with 800 million randomly generated keys).



Generating an ECDSA keys pair is as simple a generating a random private key (of e.g. 256 bits for the common P-256 parameters), and doing one point multiplication. These benchmarks show ecdonaldp256 key generation requires about 300 thousands cycles on a single core and thread of a 3.5GHz CPU, giving more than 10 thousands keys per second, over twice the requirement. And then ed25519 is more than 4 times faster.

Entropy is not an issue, we can even use manual dice throws to seed a CSPRNG, and discard the seed. Also, many modern CPUs have built-in hardware RNG with high throughput, and we can use this if we frown at having all the keys depending on the same seed (but then we still have all the keys depending on the integrity of the same computer, and what's connected to it, which is more of a security concern IMHO).

We can use several cores in parallel, and/or several computers (we can use the same seed on each job, just use the job number as an extension of the seed).

DSA key generation is significantly slower for comparable security, mostly because we need 2048-bit modulus, when P-256 works with 256-bit modulus (and only a few times more such operations). The same benchmarks show donald2048 about 4 times slower than ecdonaldp256 for key generation, and reaching the performance goal with a single computer will require some level of parallelization, but we still reach about twice the stated goal with all 4 cores of some of the CPUs benchmarked. And then high-end single-board servers may have 8 CPUs each with 18 cores.

RSA key generation is much slower for comparable security. The same benchmarks show ronald2048 as more than 1000 times slower than ecdonaldp256 for key generation. That's mostly because RSA key generation requires generating random primes, thus trial and error. Effort is dominated by failed primality tests, and attempts to reduce these. If we pre-select for testing integers not divisible by any of the 54 primes less than 256, that is about $1/10$ of integers, we still need to test about $1024\log(2)/10\approx71$ integers to find a 1024-bit prime. That 1024-bit prime generation algorithm will be dominated by about 75 executions of $x\gets a^d\bmod n$ steps in Miller-Rabin tests, each costing a 1024-bit exponentiation to nearly 1024-bit exponent; so key generation will be in the order of 75 times as costly as the exponentiations dominating an RSA signature using CRT.