I'll take a stab at explaining this.
DD4T's TridionControllerBase.Page method is decorated with the HandleError attribute. This is an inherited attribute, meaning it's also applied to your override.
Now, the HandleErrorAttribute (for which you can see the source here) replaces the view model in ViewData with its own HandleErrorInfo and renders out (by default) a view called Error.
It sounds like what's happening is that your Error page view is being picked up at this point and the attribute is passing the HandleErrorInfo to it, at which point the exception is thrown because your view expects an IPage instead. This second exception is then picked up by your global custom error handling and you're redirected to the page you actually want to be redirected to.
If you want to prevent the exception from being thrown, I think your only real option (beyond reworking your own error handling) is to extract the code from the out-of-the-box DD4T Page method (from here) and re-implement it yourself without including the HandleError attribute.
The simplest way would be to hide the existing method. Something along the lines of:
public new ActionResult Page(string pageId)
{
pageId = UriHelper.ParseUrl(pageId);
IPage model = GetModelForPage(pageId);
if (model == null) { throw new HttpException(404, "Page cannot be found"); }
ViewBag.Title = model.Title;
ViewBag.Renderer = ComponentPresentationRenderer;
return GetView(model);
}
Also, it's worth noting that you should have a static fallback error page for 500 errors - what happens if the exception is caused by a database connectivity problem and your error page has to be retrieved from the database?