I am going through the demo site and taking a look at App Architecture. I am wondering how Marco references the built-in Membership tables to his custom tables? For example, in the Orders and Forums tables, it appears as if Marco is only keeping track of user activity tied by the the AddedBy field. You can easily change the name inserted there without any consequences.

Not that important unless you start talking Orders. After looking at the SP tbh_Store_GetOrdersByCustomer, it does go after the AddedBy field to query data. I know this site is only for reference, but this points an architectural question. If you want to establish better referential integrity, how do you go about that with the Aspnet_ tables provided by the framework?

Forum posting http://p2p.wrox.com/topic.asp?TOPIC_ID=46264 touches on this, but what are everyone else's thoughts on this applying this to the real world scenarios? Do you reference the Aspnet_Users.UserID column in a non-linked fashion as a pointer back or what? I would think that this would provide the best of 2 worlds - decouple yourself physically (by not linking) but still provide a strong reference point back - correct? Or what would be other options here?

If anyone is planning on using this in real deployments (got that feeling by reviewing these forum postings), I would feel uncomfortable always relying on a easily changeable Username. Or am I off base here?

I am currently using references to UserName, ie AddedBy in my tables as Marco does but I am not allowing the UserName to be changed. As Eric suggested, a user might want to change their username, eg due to getting married or something, in which case UserId would be more appropriate but might require more coding work depending on how you set up your tables.
My next website I will use UserId from the start, however.