WordPress as CMS: a trek

Okay, I just got out of the shower (I do all my best thinking in the shower).
I think where I’m headed is toward the notion of a ‘special’ category. The ‘special’ category does not behave like normal categories.
I have already posted the example of the category which needs to hold static HTML or PHP. While I was in the shower I came up with a much more ambitious requirement, a kind of post called an event. This is to support dynamic event calendars (again, I am working on the website for a non-profit, and keeping an event calendar updated is one of the biggest challenges).
This is an application I have been working on for the last week. Since the historical society’s current hosting provider doesn’t support MySQL (I am going to get them to switch), my initial approach was to use a CSV flat file. The idea is that you edit a list of events which, when presented to the website user, is sorted by date and does not show events for dates that have already passed. Simple, but important.
So in the shower I thought about an events calendar for WordPress. At first I thought about using a ‘special’ category to allow my little PHP hack to be run. But then it occurred to me there’s already a database and admin interface. Why not use that?
So I thought about making an event a ‘special’ variety of a post. It would have all the attributes of a post, plus a start date, an end date (optional), and optional start and end times.
This could be integrated into the database either by adding fields to the wp_posts table, or by making a new table called wp_events. I don’t know which breaks the system the least.
Further integration can be achieved by allowing the events to be posted and edited using the existing admin interface (maybe a radio button on the Post screen, or perhaps a new tab for Post Event).
So when a user clicks on the Events category, he sees a list of events in chronological order. Any events which have already happened are not shown.
When the admin does the same thing, she can see all the events, and can edit or delete them as necessary (editing old events is useful when you have annual events, so all you need to do for next year’s event is edit the dates on last year’s event).
I think this should be fairly straightforward to implement. The question I have is what are the better approaches to keep it clean and separate from the main code train, so it can be easily integrated as a hack, in a way that is compatible with other hacks (such as backing up, etc).