1. I would suggest revisiting how you salt passwords for a few reasons. The main one is that since the usernames are presumably in the clear on the database, there's no reason to not take it a step further and introduce a computationally prohibitive hash. Essentially every new bit added to a salt doubles the additional processing time and storage needs for a new table. Let exponential math do the rest

.
2. SHA256 is ideally available widely for PHP5 using the hash function. PHP4 unfortunately won't have built in SHA256 support as standard - so you might be stuck with MD5 and SHA1. Work with what you have though - salting makes even MD5 less vulnerable than by itself. Also never get the idea of multiple hashing - doesn't work since hashing is designed to execute fast so multiple hashing does almost nothing to the computational cost of restating rainbow tables.
3. Watch the responsibilities. Data retrieval and ordering should be managed by a Model/Gateway/Mapper, authentication calculation by a separate Authentication library/class-family, etc. Have a look at what Zend_Auth and Zend_Db are split in the zend framework manual for example.
Finally very few people dispute the definition or interpretation of MVC actually - usually there is the issue of how the component parts are implemented inside an MVC structure.

For example ZF uses Zend_Db (TableDataGateway), Rails uses ActiveRecord, Symfony uses a full ORM like Propel, etc. Decisions within MVC is highly variable...