No, packing an executable is not just like encrypting it. The difference is that to use an encrypted executable, a secret key/passphrase is necessary, beyond the method/program to do the decryption (typically public, sometime embedded). By contrast, no key is required to run a packed executable, and how to use it often reduces to: just run it as usual; a clever piece of built-in code (a self-decompressing header) will do the rest.
Yes, you can (and it is common to) encrypt a file that is already packed/compressed, including an executable, including a self-decompressing executable, perhaps even producing a self-decrypting-then-decompressing executable; however the latter is not recommendable: it works in a world of fairy where executable file format is clearly defined, is respected by the self-decompressing header, and does not trigger a bug in the self-decrypting header.
There's nothing to prevent you from trying to pack/compress a file that is already encrypted (except if you want the result directly executable and the fairy did not bless, see above). However, that will often increase the size. There are exceptions: for example, if the encryption used ASCII armor, and the packing does not, there will likely be a moderate size gain.
Some programs pack/compress, some encrypt, some do both in one use (these are typically encryption programs happening to use compression; e.g. PGP/GPG). That's true both for general files, and when it comes to executables that remain directly executable (typically, after entering a passphrase/key if encryption was performed).
From the standpoint of cryptography, packing/compression is not encryption. A virus checker, security auditor, or perhaps customs officer, might nevertheless treat a packed file or executable as if it was encrypted, on the grounds that it is not as easily amenable to scrutiny as if it was not packed, or just as the result of some poor choice.