You've asked a lot of really good questions. Let me start with the architecture question first.
You have a lot of flexibility in how you architect a solution using the Spring MVC approach. A lot depends on the complexity. You might decide to compose a service layer that handles aggregating multiple calls to several DAO objects, which would be responsible for fetching your domain objects. If the service functionality isn't that complex, then it may just make sense to roll that into the controller and have it act as your service layer. The service layer should NOT just be a pass through proxy for calls to the DAO. Methods on the service layer should be more granular and provide cohesive business functionality. A good way to approach this is to roughly sketch the page flow from the user perspective on paper or a whiteboard and then simply begin to work it through to the back end in terms of what data you'll need. As you begin to look at required interactions, you may also begin to see logical groupings of functionality that may make a logical service layer. The controller would then simply be responsible for collecting data from the web page, validating and then calling the correct service functionality to perform the next steps.
Ok, in terms of the controller the Spring annotation way. I suspect you may indeed be getting tripped up by terminology. The term 'command object' comes from the old AbstractFormController/SimpleFormControler and from a broader pattern for doign MVC (I think Struts also uses this term). Another term that is used is 'form backing object'. This object can be a POJO and it could be a domain/model object and could even have persistence annotations (ala JPA or Hibernate). From here, I think your question is about the origin of this object and that has a lot to do with your approach to this series of pages. I assume from what you've said already that a user (me for example) would come to some starting page (/AboutYou.htm?) and begin filling out information over a series of pages. The implication is that there is a starting page, which will usually be accessed via a GET request. Usually this first invocation is where the command object is initialized. As an aside, if I was doing something similar with a specific instance (i.e. editing a product entry, which implies a product id as the key), I might pass in the product id as part of the initial GET request but initialization would probably result in a populated object (likely from a data store of some kind).
From there, the user would progress from one page to the next through a series of submits (which are POST requests). You would handle the submit for each page by doing whatever you needed to do (i.e. validating, performing calculations, etc) to set up for the next page. I found the POST -> redirect -> GET approach to work pretty well. The POST handles the binding of the data from the form to the command object. From there, I process the result and redirect to a GET request (same controller) where I prepare for the next page before returning the view to render the next form page. What makes this work is that the command object is a session object that is simply kept available to all invocations to the controller. This is made easier by the annotation based approach as there aren't the same restrictions as with the SimpleFormController.
Based on what you've posted, a controller to do all this might look like the following
I hope this helps.