Don't get me wrong, I'm not opposed to using a message system as such, it's just that from experience from group projects, the probability of them being implemented in a way which actually helps rather than hinders is rather low. An example of a really good message system can be found with Ogre's event system*, which is similar to that Normandy is proposing. However, all too often, they turn into terrible messages-for-messages'-sake which do nothing to actually help development. Which is why I'm rather cautious about it; I've seen way too many 'systems for speeding up development and making things look nice' sink entire group projects. Or in short, if the message system isn't pulled off perfectly, we garrote ourselves with our own code.
*In summary, it acts like Normandy's description, in that messages are sent out to listeners almost as if they are RSS feed readers subscribing to RSS feeds, which are then received and processed by their listeners. A system pushes the event onto the message handler, then the message handler sends it out to subscribers of that sort of message. In that way, the original sender doesn't need to know about the existence of anything using its messages, which allows for getting the data without specifically sending it to something from the original sender (which would involve editing said sender to 'aim' it at something; which we want to avoid).
As for worrying about a messaging system being too complex to code, I would say don't worry. There are a couple of experienced coders on this forum, and experienced coders know how to make things easy for themselves.
There are also many tricks up the sleeve of a computer scientist that will make the performance loss basically unnoticable.
Also, you can cut that out; you aren't the only who has coded before. >_>