overall code organization: helper, library, core, or model?

I'm taking a largish existing web application and converting to CI3. I am wondering a few things about code organization. While I understand it's probably good to have skinny controllers and fat model classes, I'm still kinda wondering where things go. I was hoping to get some advice.

Right off the bat, it seems clear to me that I need an autoloader. We used one in the old code because we had gobs and gobs of require/include statements that contributed a lot to various scripts but which also were the source of some pretty irritating bugs. I suspect that creating a pre-system hook is probably the right way to go about this as described here, but would like to hear if anyone disagrees. I especially like ivantcholakov's example, although I expect I might limit this autoloader to only apply to classes named with a specify prefix (e.g., MY_ or similar) just to be sure I avoid name collisions or similar issues. Really hope CI adopts namespaces soon.

I'm pretty sure I hate the way the loader works. It precludes the creation of static library classes, among other things. I can appreciate that it might have worked for PHP4, but that was ages ago.

I'm also hoping folks might clarify for me what exactly a helper or library is intended to describe. Seems like helpers are basically trivial functions. I'm not really sure what is meant to go in the libraries subdirectory, although an emailer or notification class jumps to mind. Perhaps folks might comment on these specific examples?

1) Data Object classes. I.e., special classes to act as intermediaries between our code and the database. These extremely useful auto-generated classes preclude the need to write any SQL for most single-record interactions (CRUD, etc). I'm definitely thinking these belong in the models directory.

2) A registry to store site-wide configuration values such as:
* email host/user/password/options
* payment gateway keys
* cloud api keys (e.g., Amazon, Rackspace, etc.)
* other?
I can't decide where this would go. Pretty sure it's not a helper.

3) Payment and business-related classes such as a 'payment router' class. I.e., business logic that guides users through a series of purchase-related pages. More specifically, a class that helps redirect a user to the optimal page based on their account status, prior purchases, session data, and other considerations. Because this is business logic so tightly linked to our business processes and data, I'm strongly inclined to call this a model, but not 100% sure.

4) Email and notification functionality. I'm thinking this should be a library, but I hate the way CI will instantiate an instance of loaded libraries and attach this instance to the current controller. I'm thinking it should go in the library directory but be loaded via my autoloader rather than CI's loader.

5) Miscellaneous cron jobs that expire offers, purge old inventory data, import new inventory data, etc.
I know that CI can be invoked via command line so I'm thinking I'll probably try and define a Cron_Controller class that fails if any methods are invoked with SAPI != CLI. Still, some of these jobs are pretty complex so I'm worrying a bit about fat controllers.

6) Code to deploy to special-purpose, dynamically-allocated distributed computing nodes.
This website has a multi-node structure where it can spawn additional servers to perform special image-crunching tasks. I've created a really complex (i.e., non-CI) codebase which must be deployed to those external machines. Seems to me this code probably doesn't belong in any CI location at all, although the web application and these remote applications do share a few classes in common.

7) Miscellaneous code to enforce user privileges derived from user access levels, subscriptions, and purchasing behavior.
This is stuff like "don't let users bid on products unless they have an account with access_level=2" and such. I wonder if this is controller or model?

Any comments/anecdotes/wisdom/constructive criticism are welcome.