Well, if it's not stored in the ledger I can't say for sure that it's bad. However, there's already a solution for the problem you describe that doesn't require a change to the Nano protocol. Just create an address for a transaction, like how Brainblocks does it. As pointed out a few comments above, your proposed solution takes up extra bandwidth, so there's already that negative about it when a solution without this drawback already exists (i.e. how Brainblocks does it).
Best design practice is to avoid unnecessary complications. Adding 8 bytes could have unforeseen complications down the road. So could adding 8 bytes for the express purpose of communicating some kind of message - that would change the purpose of Nano transactions to also include messages and Nano design might get distorted/bogged down/distracted by having to accomodate this. Nano's goal is to be the most optimized value transfer protocol possible and that means extras have to be ruthlessly discarded in my opinion.
Value transfer in foreign exchange markets is one of Nano's target use cases. FX markets are the world's biggest markets at $5 trillion/day. Colin has pointed out several times that in FX, the fastest protocol wins. If Nano doesn't avoid unnecessary extras it may not be the fastest value transfer protocol in the future. It might get trumped by some other protocol that is better optimized and faster. And for design purposes it would be a good idea to assume that speed will win in other value transfer use cases too.
If Nano is to achieve its goal of being an Internet RFC for value transfer, it has to be laser focused on this goal or risk losing out to another protocol that is better optimized for this purpose. Achieving this goal would be a colossal achievement that would bring colossal value.