Dividing an MVC model into separate classes based on operation

Based on arguments I've read about how controllers and models should be designed, there are a lot of conflicting views on MVC architecture.

There doesn't seem to be a real fundamental standard, but this article describes the pattern I'm most familiar with:

http://ift.tt/1hTnToy

Where the Book model is structured as follows:

class Book {  
    public function getBookList()  
    {
    }  

    public function getBook($title)  
    {
    }
}

In my experience, however, examples like this are too simplistic. Real applications require a lot of logic and potentially complex queries. When you start adding all the CRUD operations to a single model class, for instance, it can start becoming overwhelmingly large (i.e., a "Gob object" http://ift.tt/1F5blzD).

To resolve this, I've divided my models into separate classes based on operation. Basically, each model folder represents a namespace (noun) that is comprised of classes (verb) that contain relevant methods:

/app
    /models
        /account
            Authenticate.php
            Validate.php
            Create.php
            Get.php
            Update.php
            Delete.php
            ...

However, I was always taught that in OOP, classes represent nouns—not verbs. So I can't help but wonder whether this is bad practice. Since a lot of these operation classes contain public functions that are made up of private functions, I've considered creating a basic Account class that only includes the main public functions, such as create_account() below:

namespace models\account;

class Create
{
    public function create_account()
    {
        $this->insert_account();
        $this->insert_account_stats();
        // More functions...
    }

    private function insert_account()
    {
        // Inserts new account into `account` table
    }

    private function insert_account_stats()
    {
        // Inserts new account into `account_stats` table (normalized)
    }

    // More functions...
}

Even then, though, the Get class contains many public functions used to select Account(s) based on user input. So I still feel a single model would become too large. Is divide and conquer the way to go? I'd love to hear suggestions.