This is actually possible, but it doesn't involve the Global.asax file.
Many of Microsoft's examples demonstrate wiring code in via the Global.asax, but this is not a best-practices approach when it comes to SharePoint. Ideally, your code should get packaged as a Feature and deployed via WSP (as you already know).
The key lies in implementing the code in question as an HttpModule (i.e., a type that implements the IHttpModule interface) and wiring it into the ASP.NET pipeline servicing your SharePoint application. Roughly speaking, these are the steps:
- Create a class that implements the IHttpModule interface.
- Implement the Init method in your HttpModule; this is called when the HttpApplication (in this case, the SPHttpApplication) is setup, and it gives you an opportunity to carry out processing, wire-up event delegates for other pipeline events, etc.
- Create an SPFeatureReceiver that will add and remove your HttpModule from target web.config files on activation and deactivation, respectively. This is carried out using the SPWebConfigModification type to update the <httpModules> node in target web.config files.
- Package all as a Feature and deploy via WSP.
For more information on HttpModule development, see http://msdn.microsoft.com/en-us/library/ms227673.aspx. For some additional detail on the SPWebConfigModification type, see http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx.
Result: a class that can handle application startup and is deployable via Feature. No manual file hacking required.
I've successfully used this in a number of scenarios -- most recently with a custom caching provider (IVaryByCustomHandler) that needed to register itself for callbacks with the SPHttpApplication when it started.
Though your question is a bit older, I hope this helps!