nTier architecture for an MVC application
An accepted design pattern for separation of concerns is the Repository design pattern.  There is a pretty good description of using this design pattern in MVC here. Your example is close to this pattern in your BLL layer, although your simple example does not have any business logic and just encapsulates the DAL.  If you need to access multiple Repositories for your view it is recommended to use a Service Layer that coordinates transactions between multiple Repositories.  There is a good description of this pattern here.

Your View Model should be totally separated from the BLL and not query it directly. I assume you are querying the results in the View since you are returning an IQueryable object.  The controller for the MVC should take any query parameters from the View, pass them to the Model (Repository or Service Layer) and get back an object graph that represents the View Model, which in turn is passed to the View.  The View Model usually does not clone the objects that are manipulated in the Repository.  For example you would not need to pass things like foreign keys used for navigation in the DAL to the View Model.  Only pass to the View Model what it needs to get its job done, which is to allow the View to render a user interface.  This usually requires a lot of data mapping from one object to another. Although it is a hassle upfront you will appreciate it going forward because you will have a code base that is not fragile to changes in either your model or view.  A good tool to help with the data mapping is AutoMapper.
For a great example on how to create a robust modern website using MVC take a look at Microsoft's Silk Project.