My team has been "tasked" to create an application that follows the task-based UI (not necessarily with CQRS). I really like a UI that helps the user accomplish common tasks easily, but many pieces of this application really "feel" (to me) like a job for a typical CRUD interface (ex: all the details for a product in a catalog).
At this point, we need examples of good task-based UIs to help us see what is possible. What have you seen in the interwebs?
The easiest way to generate a task based UI is to protect all attributes/properties of your models. i.e. remove all setters.
From this (pseudo code):
public class TodoTask
{
public Date getDateAssigned();
public void setDateAssigned(Date);
public string getAssignedTo();
public void setAssignedTo(string);
}
to this:
public class TodoTask
{
public Date getDateAssigned();
public string getAssignedTo();
public void AssignTo(string userId);
}
You can't create a basic CRUD app anymore. You have to perform a task (Assign()) to update the model.
Start by removing all setters and then analyze what kind of actions (task) you should be able to do on each model.
Then you're all set.
I've blogged about it: http://blog.gauffin.org/2012/06/protect-your-data/ (scroll to the bottom to see mockups for CRUD vs Task based)
I think this would qualify as a Task Based UI. 
CRUD interfaces have a "Save" button when editing and you miss the "reason" why something changes.
For example changing the address of a customer from "Fountain St. 55" into "Birds St. 444" has the very same semantics than changing it from "Fountain St. 55" into "Fountain St. 555". Just "updated" the street.
Task-based interfaces have "Action buttons" that "mean" something of the business.
For example you could have a "Correct Address" button to signify that you are changing the address because it contained a typo and the address in fact "conceptually" is the same, only that now it reads correctly. In this case the customer did not physically move.
And then you could have another different action like "Move Customer to a new address" that means that the customer actually moved to a new place and the address change carries all that meaning.
In CRUD UIs => You "edit data".
In Task-Based UIs => You "signal that business things happened".
The second is always more powerful, although is harder to think in advance and the system must be flexible to add, carry and convey new "meanings" as they are discovered during the business operation itself.
But you get a huge benefit: Know "why" things mutate. In other words... capture the user's intent.
Microsoft Money 2000 was an example by Microsoft (although they call it Inductive User Interface. Here are the underlying guidelines and a few screenshots along the way: Microsoft Inductive User Interface Guidelines
I guess I don't really think of UI's having an appearance of being task-based or CRUD-based (although Dmitry's example is one that does demonstrates being task-based -- lots of commands). I see a task-based UI more in terms of how it interacts with the underlying domain and data model. If your interaction is nothing more than a typical out-of-the-box MVC application with action methods for Get/List/Insert/Update/Delete, then you're building a basic CRUD application. But if your forego those default action methods and create actions/commands that are meaningful to the application (e.g. add item to shopping cart, deactivate a class, etc.), then this gets more into the task-based UI world.
I do think it's a pretty gray line between the two.
As for an example, I know that a site that I work on (braincredits.com) is my attempt at a task-based UI. It's definitely a work in progress and I'm making changes to it to constantly improve it, but the implementation is command-based (e.g. post to transcript, add lesson, view transcript, etc.) and parts of it do use the CQRS pattern.
I hope this helps! Good luck!
