Should I just use an ASP.Net Web Forms site instead?
Not unless you have strict deadlines or other limitations. It's always worthwhile investing time and resources in better technologies like ASP.NET MVC.
As for using backbone.js it will work with any REST API. You can expose a REST API with ASP.NET MVC (and it's a lot easier to do then using ASP.NET winforms)
As long as you expose your data as a service backbone can work with it nicely. Alternatively you can use ASP.NET MVC on it's own and not make use of the client-side MVC backbone offers.
is it worth blending the 2 together or am I making a rod for my own back?
As mentioned if you just use ASP.NET MVC to expose data as an REST API then this is fine. If you use ASP.NET MVC to serve an entire website (including server-side views) then you'll have a lot of code duplication.
However with modern ajax and JavaScript driven websites you will have this code duplication anyway. You might as well use backbone or not use any client-side JavaScript / ajax code.
If your writing a heavy client based website with lots of interactive JavaScript based ui you might aswell use these libraries to structure and organise your code
However if your using backbone.js I would recommend you couple it with node.js to minimize code duplication or couchapp to remove the server-side stack. You don't really need .NET if your using backbone.
EDIT: To summarise, I think understand where you're coming from - at first glance, the ASP.Net MVC framework seems to have (too) many parts, and it's difficult to start understanding it. Having said this, I'd argue that you're looking at this wrong. ASP.Net MVC is not a particularly heavy MVC framework (you should compare it to PHP MVC frameworks to be fair), but yes, it is very much conventions-based. There is a lot of good reasoning behind that design choice, and your first priority in learning the framework would be to learn its conventions, and perhaps the reasoning for them. If for some reason you absolutely want to go deeper, the framework is open source, and you can dig into it here.
I can just skip frameworks altogether, and toss random PHP along with my HTML on a single file and make it work
Well, not with an MVC framework (even in PHP). You're going to at least have a model, a view, and a controller. Those are a bit of a minimum, so I'm not really sure what you're looking for here; it's an apples and oranges comparison.
After that, there's going to be a few other files that you will probably need; such as configuration for the routing, etc. This is fairly standard and comparable to PHP MVC frameworks.
If you want a "single page" model, you could try WebForms, although that technology typically tries to move logic into a separate "code behind" page. I'm pretty sure you could skip the latter, however, and have .aspx files logically identical to .php files sitting there.
Do I really need to create a whole bloat of files and folders...
The default VS project template does tend to copy a lot of potentially unnecessary stuff (scripts, etc), but you could remove most of those. Again, you will probably have a minimum number of things there. Do these really cause you major worry? Have you seen what a Symfony installation looks like?
... for the sake of convention?
Convention is a great thing. The concept is called "convention over configuration", and for most non-trivial projects, it is wonderful thing. It stops people from reinventing things, and gives standards that should be followed.
Since you mention this is a learning exercise, I would suggest that you stop worrying about these things too much. ASP.Net MVC is very much about convention, and you are doing yourself a disservice by trying to work around those. In fact, to learn MVC, you should learn the conventions as much as any of the internals.
Best Answer
I deal with a similar issue in an app (super long log-in state), and resolved it by storing a GUID in a cookie on the client (via HttpOnly cookie) that is tied to a single login event record on the server.
Technically if someone had physical access to a logged in machine, they could see the cookie and copy the GUID value to be used elsewhere but if they did that, then they already have access to the logged in machine so its pointless to worry about anyway.