Alright folks I've found my answer to what I wanted to know: "Is there any way to modularize the way Sitefinity works with MVC (e.g. splitting different widgets into areas or separate projects)."
And the answer is a big fat maybe and I'll explain why.
The main sitefinity class responsible for bootstrapping is Telerik.Sitefinity.Services.SystemManager which is a static monolith. Inside this class there is a method called Initialize which is responsible for all the bootstrapping and on one particular line it calls new MvcCore().EnableMvcSupport();.
Now the MvcCore class is responsible for creating the Mvc ViewEngine, registering all the controllers, and areas. Inside the EnableMvcSupport it creates a SitefinityViewEngine and adds it to the ViewEngines.Engines.
So due to this design there is no way to actually modify the SitefinityViewEngine and inject it into Sitefinity (mostly due to a lack of DI and the usage of static classes). So what is the way to get around this? The current answer is wait until Sitefinity has done its bootstrapping and simply remove the SitefinityViewEngine from the ViewEngines.Engines and register your own. It feels very hacky, but that's probably the only way to extend it (if it even works since I haven't tried it yet).
Alright I have confirmed that the ViewEngine can be replace in the manner I described.
Here is my implementation:
Create a Global.asax file in the SitefinityWebApp root.
In the Application_Start add these lines:
ViewEngines.Engines.Clear(); //Gets rid of the default SitefinityViewEngine
ViewEngines.Engines.Add(new SitefinityContribViewEngine("MVC")); // You can change MVC to match whatever you want. I just leave it empty so it will default to null which will resolve controllers/views to the site root like regular MVC.
I haven't confirmed that this breaks anything, but I am able to create controller widgets located at ~/Controllers and add them to my layouts with no problems.