With a bit of math, it should be possible to devise a sequence of zlib flush blocks (and other tricks) that don't affect the PNG checksum, either.
As for the "other tricks", you can get 10 bits of do-nothing padding by starting and immediately ending a fixed-huffman block, and various other lengths by starting and immediately ending dynamic huffman blocks. I use the former in unPNG[1] to pad things out to word boundaries, for alignment.
There is a much easier way. You can put an arbitrary number of empty uncompressed blocks, which are normally used for the sync flush (Z_SYNC_FLUSH in zlib). Such blocks do not affect any other block or zlib checksum (but do affect PNG checksum). For example a DEFLATE stream `7801 (00 0000 ffff)* 01 0100 feff xx yyyy yyyy` is always valid and decompresses into a single byte `xx` where `yyyy` is a big-endian representation of `xx + 1`. Also PNG IDAT chunks have to be implicitly concatenated, so you can technically have an arbitrary large PNG file of single pixel if you really want.