I've been reading a lot of posts on how to get debugging going when attaching to the w3wp.exe process.
Disable 'Enable Just My Code' in Visual Studio
This blog post started me off in the correct direction by setting the Tools | Options | Debugging setting correctly.

Modify the web.config

Furthermore, it prompted me to change the web.config value from debug="false" to debug="true". The web.config file can be found in the Inetpub\wwwroot\wss\VirtualDirectories\ folder, each folder in there maps to an IIS Web Application which you can find by going to IIS Manager and looking at the Home Directory.

To get full blown ASP.NET errors rather than SharePoint branded "useless" ones follow these steps:

Setting CallStack=true
By default, WSS will redirect a user to the error page whenever an unhandled exception is encountered during the render cycle.  To disable this behavior, open your web.config and set CallStack="true" in the <SafeMode> node.  This allows you to see a typical Asp.net error page.

Setting customErrors mode…
The next step would be set mode=”Off” in the <customErrors> node.  This instructs Asp.net to show you a complete error report rather than a generic “Server Error” page.

Creating pdbs

For each project you wish to debug, you need to ensure that you are creating pdbs. I am using the really cool stsdev app to create my projects and had to modify it to create pdbs by going to Project Properties and on the Build tab in the Output Section click the Advanced button.

Then ensure that Debug Info is set to pdb-only.

Attach to Process

The author of the previous referenced post also pointed me to running iisapp on the command line to output a list of all the running instance to know which process to attach to:

Then when you select Debug | Attach to Process the ID matches to the PID in the output of iisapp. Note you need to check 'Show processes from all users' as w3wp.exe will be typically running as another account.

You can check that you have the correct id by pressing CTRL-ALT-U and this will list all the Modules that are loaded with statuses on the symbols that are available (e.g. that when you create a breakpoint it'll work rather than giving you a 'No symbols loaded' errror).

Notes for Visual Studio Debugging Newbies

Once you are actually debugging and can step through code after it breaks on a breakpoint...you can also use the Immediate window to inspect objects by pressing CTRL-ALT-I. From here you can get up intellisense on any object in context which is a great way to inspect things like whether a SharePoint list has an Event Receiver on it or not.