Refactoring a database using VIEWS

Question

I have the task of refactoring a database and would like to know if VIEWs are viable for the task.
My strategy is to create a VIEW imitating the new structure of the supposed table, at least the name of the table (name of the VIEW) and fields (column aliases), until the changes are confirmed and I can create the TABLE in fact.
The concern I have is about the performance and feasibility of integrating the VIEWS with the layer DAO, which I am also still implementing.
The layer of DAO I will implement anyway, whether reflecting the VIEWS or TABLES, and chose VIEWS to precisely impact it on little or even nothing.

I wonder if anyone has ever done something like this and whether this strategy with VIEWs is feasible to refactor a database as described.

PS1: I intend to build the VIEWs following the instructions of part of the documentation, which defines when the VIEWs sane insertable/updatable.
The current BD has 150+ tables, and some tables have up to 50+ columns. The system is written in PHP without any standard or architecture. There are several JOINs, Some make sense and some don’t, and the intention will be to rewrite most of the queries, because their performance is deplorable.
The bank does not follow any normalization standard, but since it is a huge structure, I believe it will generate a somewhat complex structure in these terms after remodeling it.
Another thing to consider is that the new structure and the old one will inhabit the same database, I will only be able to get rid of the old structure at the end of the project, when it is already completely obsolete.
The DAO should ideally support both the physical tables and the VIEWs, but I believe I could create a DAO for each case.

PS2: The library you want to use will be the Activerecord
DDL of part of a current table:

CREATE TABLE Usuarios {
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `user_name` varchar(16) NOT NULL DEFAULT '',
    `user_pass` varchar(255) NOT NULL,
    `flag_ativo` varchar(255) NOT NULL DEFAULT 'ON' #ativo ou nao varia entre ON e OFF, respectivamente
}

Example of a VIEW, where the result would reflect the restructured table:

SELECT
    `Usuarios`.`id` AS `cd_usuario`,
    `Usuarios`.`user_name` AS `de_usuario`,
    `Usuarios`.`user_pass` AS `de_senha`,
    IF ((`Usuarios`.`flag_ativo` = 'ON'), 1, 0) AS `fl_ativo`
FROM
    `Usuarios`

An intended DAO, reflecting the VIEW which would be the actual table already remodels:

class Usuarios extends ActiveRecord\Model {
    //table_name é um atributo da ActiveRecord\Model
    static $table_name = 'tb_usuarios';

    //Também atributo da ActiveRecord\Model
    static $primary_key = 'cd_usuario';

    //De uso interno da classe, faria isso para cada campo
    static $de_usuario = 'de_usuario';

    static $de_senha = 'de_senha';

    static $fl_ativo = 'fl_ativo';

    public function validaLogin($user, $pass) {
        $usuario = self::first(
                     array('conditions' => 
                         array(
                             self::$de_usuario.' = ? AND '.
                             self::$de_senha.' = ? AND '.
                             self::$fl_ativo.' = ?', 
                             $user, 
                             md5($pass),
                             1
                         )
                     )
        );
        return $usuario !== null;
    }
}