Answers:
Wow, great question! Let me try to explain the resolution. It'll take three distinct steps.
The first thing to note is that the entropy is focused more on the average number of bits needed per draw, not the maximum number of bits needed.
With your sampling procedure, the maximum number of random bits needed per draw is bits, but the average number of bits needed is 2 bits (the average of a geometric distribution with ) -- this is because there is a probability that you only need 1 bit (if the first bit turns out to be 1), a probability that you only need 2 bits (if the first two bits turn out to be 01), a probability that you only need 3 bits (if the first three bits turn out to be 001), and so on.
The second thing to note is that the entropy doesn't really capture the average number of bits needed for a single draw. Instead, the entropy captures the amortized number of bits needed to sample i.i.d. draws from this distribution. Suppose we need bits to sample draws; then the entropy is the limit of as .
The third thing to note is that, with this distribution, you can sample i.i.d. draws with fewer bits than needed to repeatedly sample one draw. Suppose you naively decided to draw one sample (takes 2 random bits on average), then draw another sample (using 2 more random bits on average), and so on, until you've repeated this times. That would require about random bits on average.
But it turns out there's a way to sample from draws using fewer than bits. It's hard to believe, but it's true!
Let me give you the intuition. Suppose you wrote down the result of sampling draws, where is really large. Then the result could be specified as a -bit string. This -bit string will be mostly 0's, with a few 1's in it: in particular, on average it will have about 1's (could be more or less than that, but if is sufficiently large, usually the number will be close to that). The length of the gaps between the 1's are random, but will typically be somewhere vaguely in the vicinity of (could easily be half that or twice that or even more, but of that order of magnitude). Of course, instead of writing down the entire -bit string, we could write it down more succinctly by writing down a list of the lengths of the gaps -- that carries all the same information, in a more compressed format. How much more succinct? Well, we'll usually need about bits to represent the length of each gap; and there will be about gaps; so we'll need in total about bits (could be a bit more, could be a bit less, but if is sufficiently large, it'll usually be close to that). That's a lot shorter than a
i.i.d. draws from this geometric distribution, so you'll need in total roughly random bits. (It could be a small constant factor larger, but not too much larger.) And, notice is that this is much smaller than bits.
So, we can sample i.i.d. draws from your distribution, using just random bits (roughly). Recall that the entropy is . So this means that you should expect the entropy to be (roughly) . That's off by a little bit, because the above calculation was sketchy and crude -- but hopefully it gives you some intuition for why the entropy is what it is, and why everything is consistent and reasonable.
You can think this backwards: consider the problem of binary encoding instead of generation. Suppose that you have a source that emits symbols with , . For example, if , we get . So (Shannon tells us) there is an uniquely decodable binary encoding , where (data bits), such that we need, on average, about data bits for each original symbol .
(In case you are wondering how such encoding can exists, given that we have only two source symbols, and it seems that we cannot do better that the trivial encoding , , , with one bit per symbol, you need to understand that to approximate the Shannon bound we need to take "extensions" of the source, that is, to code sequences of inputs as a whole. See in particular arithmetic encoding).
Once the above is clear, if we assume we have an invertible mapping , and noticing that, in the Shannon limit must have maximum entropy (1 bit of information per bit of data), i.e., has the statistics of a fair coin, then we have a generation scheme at hand: draw random bits (here has no relation with ) with a fair coin, interpret it as the output of the encoder, and decode from it. In this way, will have the desired probability distribution, and we need (in average) coins to generate each value of .