That's not quite true, but I think it should hold for this in particular. Some other counterexamples besides "nothing" would be if it generated a regular pattern like "101010101" or if it picked up some kind of mostly predictable input, like a radio station or GPS data. You definitely don't want to dilute your entropy pool with something that can be predicted.
Is "dilute" really what happens? I'm not an expert on this, but my understanding was that you cannot do any harm by feeding predictable data into your entropy pool. The absolute worst case is no improvement over what you had before. In other words, keyboard/mouse/HD/IO/etc. timings plus GPS data is at least no LESS secure than just keyboard/mouse/HD/IO/etc. timings. Is that wrong?
You're correct. You can't dilute it by adding anything to the pool. However if you also increase the amount of entropy that the system thinks is in the pool this can cause issues. The system keeps a log of the amount of entropy that it thinks the pool has. This is reduced when in some cases for example when urandom is used. When the entropy remaining runs out urandom will have to wait for more. You can specifically tell the system "I've added lots of entropy" and then urandom will not stall but may make some not-very-random random numbers. So adding to the pool is a good thing but don't tell the system it has more entropy and don't expect to get random numbers faster.
That is what I meant by "dilute", yes. Not a perfect metaphor, I guess. In point of fact, only /dev/random would be affected by that. /dev/urandom does not stall when it runs out of entropy; it just reuses the entropy in the pool and hopes for the best.
Yes. However, running your own entropy generator looks ok to me (which is then fed to a random number generator)
Unless your entropy generator is only generating "nothing" this shouldn't be a problem beyond possible attacks to reading of the data