Debugging a feature activation is relatively easy (even remotely), you simply attach to the w3wp.exe process that is running your particular SharePoint instance.  However, I have found that if you need to debug a feature that is activated with stsadm.exe, there is an extra step required.  The reason is that you need to not only attach to the w3wp.exe process but you also need to attach to stsadm.exe as well.  Of course, if you execute your stsadm command, then jump into Visual Studio and try to attach to the process, stsadm has probably already completed by the time you get there.  How do you get around this?  Well I can think of two ways.  One is cheesy but effective and one is a little more elegant. 

The Pause/Break Key

Yes, this old key from back in the DOS days (well probably earlier), can be your friend here.  First start out in Visual Studio and attach to the appropriate w3wp.exe process.  Next, go to your command prompt, run your feature activation command and quickly press the Pause/Break key.  The stsadm command will be paused.  Now, go back into Visual Studio and attach to the stsadm.exe process.  Once you are attached, go back to the command prompt and press any key and you will be good to go.  This is pretty cheesy as I said, but it does work pretty well.

System.Diagnostics.Debugger.Launch()

If you want a more elegant solution, you can launch the debugger via code in your feature receiver.  Simply, add the following code to get started.

System.Diagnostics.Debugger.Launch();

When you activate the feature, a Visual Studio dialog will pop up asking you where you want to debug your process, just choose the Visual Studio project that contains your source code (assuming you already have Visual Studio open with that project).  This is also the technique I use when I need to debug custom stsadm commands.  Once you are done debugging, you will of course want to remove the line launching the debugger.