WCF adds an abstraction over MSMQ. In fact, once you define compatible contracts (operations must be OneWay), you can switch out MSMQ in the config, transparently. (For instance, you could switch to normal HttpWS or a NetTcp binding.)
You should evaluate the other WCF benefits, like security and so on, to see how those fit in with your needs. Again, they should be reasonably transparent of the fact you're using MSMQ underneath. For instance, adding SOAP security and so on should "just work", independent of using MSMQ.
(Although, IIRC, you still need to login to the desktop on each machine that uses MSMQ, with the service account that will use MSMQ, to generate the certificate in the machines local profile. And then, it doesn't work very well from IIS6, since user profiles aren't loaded. A real pain in general, but nothing to do with WCF specifically.)
Apart from that:
Have you looked at SQL Server Service Broker? After using MSMQ + WCF and SSSB, I think that SSSB is vastly easier to configure and manage. SSSB works with T-SQL commands over any SQL client (I use it from Mono, on Linux, with transactions). It'll also give you transactional send/receive, even remotely (I think MSMQ 4 now allows this). It really takes a lot of the pain away from message queuing, and if you're using SQL Server already...
SSSB is often overlooked since the SQL Management Studio doesn't have GUI designers for it all, but it isn't hard and is a great option. The one downside is that if you want local send capability (i.e., queue message when network is down), you'll need to run a local SQL Express instance.
Best Answer
I'd recommend staying away from hand-rolled solutions as there is a bunch of somewhat difficult stuff that needs to be gotten just right - like how transactions are handled, how exceptions cause rollbacks, how to stop rolling back endlessly (poison messages), how to integrate with long-running workflows so that the state management boundaries line up, and more.
You will probably want some kind of durable/transactional messaging infrastructure, so not using MSMQ you'd be left with Service Broker on the Microsoft platform, or some other alternative like ActiveMQ. MSMQ has the benefit of already being installed on all Windows machines, as opposed to Service Broker which isn't.
In terms of choosing between NServiceBus, Mass Transit, and Rhino Service Bus - this Stackoverflow answer comparing NServiceBus to MassTransit would be a good place to start..
In our 3.1 release, we're introducing NSB Studio - a set of Visual Studio integrated modeling tools that enable you to model your system at a higher level of abstraction and have much of the configuration and initialization of NServiceBus be done for you automatically. I'd say that this really tips the scales in favor of NServiceBus.
Hope that helps.
Disclaimer: I am the author of NServiceBus.