I realize this response may not answer your question, but I still hope that it may be of some help.
Your 'magic number' should really depend upon both your application, and the type of memory corruption you want to detect or are expecting.
I've seen OSes that initialized a task's entire stack with 0xEE--a value that is both easily recognizable and unlikely to be used by most people. This method could be used to guesstimate the amount of unused stack space by counting the the 0xEE bytes. Is it perfect--no; but it is quick, (fairly) cheap and easy to do. One of the benefits to this is that you can sometimes easily identify which bytes are getting corrupted (say if you have a couple of non-0xEE bytes in a sea of 0xEE bytes). The basic idea should be transferrable to other areas.
You could go the custom route and have a unique magic number per data structure--say a CRC. It's more expensive, but it will be better at detecting whether the data structure has been corrupted or not. It will not tell you where/how/when it was corrupted, but only whether it was or wasn't. This unfortunately would fail your human readable request.
If your memory blocks are large enough, it might be possible and practical to take advantage of the MMU and protect your memory blocks by disabling writes to them by default, and enabling them only for the duration of time you need to make changes. This method would have some write performance penalties, but it can help detect when, where and by whom the corruption is occurring. This completely eliminates the magic number.
Hope this helps.