Hi Rick,
When I say "bolt on" feature it means it is not fully visually integrated in the way that CMS plugin features are, it means just building whatever you want without really following the guidance for feature development.
So if you make some .aspx page and add it into mojoPortal that is pretty much a bolt on feature. You could link to it from the menu or admin menu or from content, but it won't be visually integrated like when you do follow the guidance for feature development. You could use mojoBasePage in a bolt on feature and then it would be somehwat visually integrated because it would use the skinning system but when you link to it it will not highlight the menu correctly because it is not like a supporting page where the pageid is passed in the url and the context of the cms page is maintained in the menu.
So just bolting stuff on is not a good way to make a CMS plugin feature, but if you just want to have some functionality running in your mojoPortal site and don't care about the visual integration you can do whatever you like. You can choose not to use mojoBasePage (In Site Analytics for example does not use mojoBasePage), and therefore you would be free to use MVC or whatever you like, but the tradeoff is that you don't get the same benefots of visual integration that you get if you develop features in the way we recommend for CMS plugins.
If you check out In Site Analytics Pro on the demo site, Administration > Site Traffic Reports, you will see what I mean. It runs in the mojoPortal site and it links into the admin menu, but it could have just as easily been a standalone app except then you would have to implement your own user security. In Site Analytics was designed to run in mojoPortal and not be standalone because it does rely on mojoPortal users and roles and site settings and other stuff like that. But the UI doesn't use mojoBasePage and has a look and feel separate from the site skins. I implemented a base page named AnalyticsBasePage for that app and all the pages use it instead of mojoBasePage. I did re-use some controls from mojoPortal which was part of the reason I chose to WebForms for that, though it could have been implemented using MVC.
So I don't really forsee any tutorial for bolt on features because there are no rules, you do whatever you want and use whatever you want but you don't get the same benefits as you get when you develop CMS plugin features using the recommended approach, though you do get the benefit of still being able to use things available in mojoPortal such as users and roles, (Controls if you use WebForms) utility methods etc.
CMS plugin features are also designed to support multiple instances of the feature but for things that don't really need to support multiple instances and aren't CMS features per se, and don't need to plugin to CMS pages and don't need to be as visually integrated as CMS features, or especially features that are not meant for your visitors but only for backend admins to use, then it is perfectly reasonable to implement a bolt on feature.
Hope that clears up what I mean by bolt on features. There is no guidance or tutorial coming from me on building bolt on features because there is not just one way to do it, it is wide open.
Best,
Joe