MVVM Relay Command

I've just reviewed Josh Smith's ubiquitous ariticle on MVVM for the umpteenth time.  Everytime I read it I keep thinking that the Relay Command is nonsense.  Was wondering what your thoughts were?

Reason:  When we start learning Agile and in particular refactoring, we are trying to get to one-time one-place.  This as well as SOC (Separation of Concerns) or "Each Class is responsible for itself".   The VISUAL STUDIO IDE is geared toward new users being able to wire up button events by just double clicking on the button and having an event autocreated in the View's code.  During Winform days and prior to learning more about good programming practices, it wasn't that hard to find a zillion lines of code in any View out there.  Times have changed but VS has not as it still lends to this "Get it up and running" philosophy, which is Agiles' first rule, just get it up and running, then refactor.

Along comes MVC, MVP and MVVM.  MVVM being most familar to WPF folks.  Definitely a step towards better SOC.  Clear, Easy and a good model overall, but....some articles tend to "Clog" the ViewModel with stuff that really isn't SOC.  My particular beef is with Commands.  To me a Command is a Command and should be separate from the ViewModel.  The chief reason being that a particular command such as GetCustomer could be reused.  The other reason is all maintainence for the command is unto itself, and not comingled with the ViewModel.  So how does the command living on it's own interface with the Model and ViewModel?  Simple, it invokes the Model getter logic whatever that may be (Model.GetCustomer) and the model, then fires a DataReadyEvent when it's ready.  Ok so we do have close coupling between the command and the model but, after all, the command name is "GetCustomer"...

There's even the possibility of the Model implementing the command interface.  Which could be cleaner, but the purists may say the View can't know the Model.  Ok, fine, then let's just keep it in its own Folder named Commands.

How about this one?  EF4.0 makes database modeling simple, we now have complete Class mapping (ORM) ability of the database.  It could be argued that all Business Logic can now be pushed to the ORM.  This means that we now have automated MODEL class level code generation, minus the business logic.  The virtual methods of the Entity Framework now allows anyone to put in partial method hook implementation which is perfectly suited for Business Logic.  Wow!  Looks like the developer really only has to focus on the View and View Model and Commands as the MODEL is almost completely automated now. 

Really now, shouldn't there be automated ViewModel ability?  All the work to hook up Getters and Setters is boring and repetitive...That screams for a refactor...doesn't it?  And, yes, BTW, don't even get started on DPs (Dependency Properites) Because now you're going to spend another three days just wiring them up....  Here's what we need...

1) Automated ViewModel generation based on either the View or a simplified ViewModel.

  I understand that Caliburn does some automated ViewModel work.

2) Automated DependencyProperty and Metadata framework within Visual Studio. 

  I haven't seen anyone tackle that one yet.

I don't think that we need to be spending the tons of hours needed to expose properties and set up bindings.  It's too common of a chore, boring, and repetitive. 

Agree?  Disagree?