<p>How would make a news feed "friendly" database design, so that it wouldn't be extremely expensive to get all of the items (query) to put in the news feed?  The only way I can think of would involve UNIONing nearly every table (representing groups, notes, friends, etc) and getting the dates and such, that just seems like it'd be a really expensive query to run for each user, and it'd be pretty hard to cache something like that with everyone's being different.</p>

Firstly, consider doing a performance prototype to check your hunch that the union would be too expensive. You may be prematurely optimisizing something that is not an issue.
If it is a real issue, consider a table designed purely to hold the event feed data, that must be updated in parallel with the other tables.
E.g. when you create a Note record, also create an event record in the Event table with the date, description, and user involved.
Consider an indexing the Event table based on UserId (or UserId and Date). Also consider clearing old data when it is no longer required.
This isn't a normalised schema, but it may be faster if getting an event feed is a frequent operation.