You don't want to setup IIS using clustering services. This is not what Windows Clustering is for. At it's core, Windows Clustering is for restarting a service if it crashes-- but with the ability to restart the service on another machine if the machine fails. You will not achieve any of your goals and you will confuse the heck out of everyone.
You will want to setup two standalone IIS servers. You will want to setup a file share that uses Windows clustering. You will create a virtual directory on each IIS server that maps to the clustered file share you created.
You will then need to load balance the two IIS servers. I would suggest NLB because it's quick and does the job but you won't do it for some reason. Up until recently I was using NLB on 10 web servers and getting 240 million page views a month with no issues.
I don't know how you will load balance your web servers unless you have a load balancing device or some other software.
So, in review:
Scenario A: You have two web servers running at 35%. One crashes. Your load balancer continues to direct traffic to the remaining web server which is now at 70%.
Scenario B: If you used Windows Clustering you would have two web servers running at 35%. One crashes and causes another instance of IIS to be started on the other node. Now you have one node running two instances of IIS at 70%-- which is exactly where you are in scenario A except now you have tons of pointless overhead in running a Windows cluster that isn't being used correctly.
You have a Windows file share cluster. One machine crashes. The fileshare fails over and things continue as normal.
Same as fileshare.
You could put your fileshare and SQL on the same cluster. You won't have any issues.
So, you need four machines and one shared storage. Two standalone web server, two nodes for a Windows cluster with shared storage with one node running SQL and the other running the fileshare (or both on the same node).
Don't overcomplicate things. Keep it simple.