This sounds dangerous as the only way to achieve this would be to access the current httpcontext within your feature receiver and redirect the response to your custom application page. This will work just use the following code:
Dim context As HttpContext = HttpContext.Current
The problem with this approach is that you are essentially hijacking the request and redirecting it without allowing any further code to execute. So this could cause serious implications with regard to object disposal and other issues.
The other problem is that SP will not think that the feature is activated as you have not executed any further code beyond your redirect.
You can do what you like in the application page so you could activate another hidden feature that makes the true changes (based on the users actions on the application page) however SP will still display the original feature as unactivated in the UI. If you try to activate the original feature via the UI in the application page then you'll end up being redirected back to your application page when the feature receiver runs again. You could try to wrap the above code in some logic so it will redirect if called from the UI but not from the API maybe inject some additional data in with the API call or set a value on the SPWeb's property bag (SPWeb.Properties.)
It is highly likely that there are hidden problems and issues with this that are not obvious at first. I would get a very clear idea of what code you are not executing by hijacking the response in this fashion.
Either way this is a pneumatic drill to crack a nut. What is the requirement that needs this approach? I suspect if you revisit the actual requirement you will find a better approach then this. It does appear to be achievable though.
As @Wictor has pointed out on another thread for a similar question this approach would not work if the feature was being activated outside of the HttpContext i.e. via STSADM. This is a big issue. Do not follow this approach. I said there would be problems with this approach.