ASP.NET MVC uses its own structure. There are excellent books on how ASP.NET MVC works, including Professional ASP.NET MVC 1.0 by Wrox. Understanding why ASP.NET MVC differs from ASP.NET and why it does what it does is crucial to utilizing it correctly.
MVC uses its own file structure, as I alluded to before:
This file structure is 'by default' or as MVC-types call it, "Convention over configuration". If you install Visual Studio 2008, and start a new ASP.NET MVC 1.0 project, you'll find that this structure has been created for you.
With regards to deployment, there are plenty of Stack Overflow questions that deal with that.
If you learn by reading books I would suggest checking out Professional ASP.NET MVC 1.0. It is written by Scott Hanselman, Phil Haack, Scott Guthrie and Rob Conery. Here you can download a whole chapter of the book for free which walks you through building an application entitled, "Nerd Dinner", from start to finish.
If you learn by example, then perhaps you would like to check out "Haackoverflow". It is a Stackoverflow-esque site created in ASP.NET MVC where you can post questions and answers. You can watch the video of it being created here on channel9.
Finally, if you are a visual learner I would highly suggest checking out the tutorial videos on the official ASP.NET MVC website. They cover topics such as routing, views, controller, validation, security, etc.
When searching the net or watching videos, be sure they are for version 1.0 or greater. There have been some breaking changes from the pre-release versions and they will only serve to confuse you.
If you have a service layer and your're using it in a way that abstracts the business logic away from the repository (as you should with a service layer) then no, your controllers should only be making calls to the service methods. The service layer will then be the coupling to the repo.
Further to Mayo's answer: the model are the data classes that will be passed throughout the application (repo, service and UI/controllers) so the UI/web layer should 'operate' on them just like the other layers will.
I think if you implement a service layer in the context of Fowler's definition and the modern aspnet mvc adaptions, then you should have your controller actions designed as very small and lightweight methods, calling the 'meaty' business logic from your service layer.
EDIT: I guess i wasn't clear: I'm not saying having a service layer is the only option, just trying to answer part of the question pertaining to the case where you do use a service layer. Agreed, a service layer is not always necessary, especially for smaller projects.
Recently read ASP.NET 3.5 Application Architecture and Design - it was a reasonable look into many different aspects of design within ASP.NET, including Data Access Layers, N-Tier architecture, Design Patterns and touched on MVC, amongst other topics. It was good as an overview of ASP.NET best practices, if looking for a book.
I would have to agree with others that you're best bet would be to look at going straight to ASP.NET MVC as your current skills will translate better to that framework. I would recommend taking a look at Professional ASP.NET MVC 1.0.