As with any software application there will be a learning curve, but when you combine these different technologies the learning curve becomes much larger. Add a myriad of configuration settings, and extensive IDE and security precautions and it is overwhelming. No one becomes an expert in a day, period.
Most of what you have mentioned has nothing to do with DotNetNuke. Your problems are configuration issues with IIS and Visual Studio.
First of all, you should dedicate a workstation with Visual Studio, IIS, SQL Server, .net, DotNetNuke to work with source code and debug locally. Why? Because it is the quickest way to see things work. You should be able to get this part working before attempting debugging or even considering remote debugging.
Your information is confusing. Are you running locally or on a server? Why do you have IIS directory browsing turned on? What is the startup project in the IDE? What is the startup page in the IDE?Did you move DotNetNuke from a local installation to a server?
Finally, what specific errors are you getting? Normally DotNetNuke works fine, until someone experiments with IIS, file permissions or web.config. In many situations DotNetNuke startup errors will be recognized by the community and a simple related tweak will get you up and running.
Another common mistake is to find an error during installation – fix the problem – then continue installing the partially installed application. This will leave your app in an unknown state and guarantee other issues later on. In this case you should reinstall from scratch, meaning delete the database and all files in the virtual folder and reinstall and restore config settings.
One does not need a debugger to follow instructions.