Disclaimer: I am writing this based only on what you write and my own guesswork.
Last I saw something about "encrypted tokens", it was about server load. When an app uses such a token, the token must be verified against what can be described as a big database of all existing valid tokens. Possibly, some people could have begun to try "random tokens" just in case it works (cost of trying a random token is about 0 for an amateur who will just try out a dozen or so, but the perceived potential gain is high). Risks of hitting a valid token are negligible (if the token includes enough secret random bits) but each such token must still be validated against the Big Database, and given the size of Facebook's user base, one can surmise that this implies a tremendous extra load on that database.
A way to reduce such load is to use a MAC: a keyed integrity check. Facebook's servers would first verify the MAC (with the secret key used to generated the MAC in the first place) and only tokens with a proper MAC would be forwarded to the database for the more expensive verification.
There are several methods to make a keyed integrity check; one of them is to add some "redundancy" in the token structure (e.g. a field consisting in a sequence of zeros) and then encrypting the whole with a pseudo-random permutation (a block cipher, using the whole token as a single "block"). To verify, the token is decrypted and the presence of the redundancy is verified. There is ample room for doing it wrong (e.g. if the token is longer than a cipher block, and an inadequate chaining mode is used) but it is still a possibility.
Therefore, without any other information, I find it possible that the "encrypted token" could be a keyed integrity check in disguise, meant to reduce server load.