Well, your definition of entropy is known as Kolmogorov complexity, and it's not so much that it is incorrect, as it is that it is inapplicable to what gzip does.
For example, the value $\pi$ can also be generated by a short program; however, if you attempt to compress a 2.2Mbyte sample of the binary expansion, you'll also find that gzip will also not be able to compress it.
What we can tell from that is that gzip doesn't actually do a good job of estimating the Kolmogorov complexity. Now, this is not actually a major criticism of gzip; it is actually impossible to write a program that computes it (!).
Instead of attempting to wrestle with Kolmogorov complexity, what gzip (and every other compression algorithm out there) relies on to compress the data is heuristics. That is, it has a model of redundancies that appear in real plaintexts (such as repeated substrings), and is able to take advantage of those redundancies to shorten the length. Now, if that model corresponds to the text it is given, gzip can compress quite well; if the model doesn't correspond (and both the encrypted text and the binary expansion of $\pi$ fall in this camp), it can't compress at all.
And, no, encrypting more data would not make the result any more compressible.
If you compress first and then encrypt, the file will be smaller and more secure. (When the plaintext's cryptographic entropy is a lot less than the ciphertext's length, it enables what's called a guessable-plaintext attack.)
