Alerts are generated in two phases. The first phase is done when the item is saved that would generate alert and that is done in the context of the application pool. It creates a summary of what changed on the item and saves that to a table inside SharePoint. The second is a Timer Job that checks all defined alerts against the table of changes and then generates the emails.
However, if you are looking at extensive customization of the alerts, I would strongly recommend that you either limit your customizations to simple html formatting changes, or replace the alert email generation logic entirely. Trying to go halfway will not work out well. Also, don't forget that Alerts also include Digest alerts (the daily/weekly summaries) and those are handled quite a bit differently.
My advice would be to push back as much as possible on custom alerts. If they insist on them, then double your estimate right now. I'm not saying that to try to discourage them or to line your pockets, merely that Custom Alerts look very simple to do but end up being far, far more complicated - especially the digest alerts.
If they want to add a field to the alert that is not there now, triple your estimate. Why? As I said, alerts are done in two phases - the first creates a delta, the second creates the email. At the point of email generation (when your handler executes) you only have access to the delta, not to the original old/new item. So, if you want to add a field that was not in the alert originally and not in the delta, then you need to track down the old/new version of the item yourself. If you are working with a list that is not using versioning, well, good luck with that - especially if someone has updated the item again since the change, which is very likely for digest alerts given the timespan they cover.