1. I typically start by defining namespaces per module and placing them in folders. A common mistake is to add unnecessary complexity by separating into XAPs before it's really needed. You can start with modules as folders and namespaces and then refactor
into separate XAPs when you identify the need.
2. The service client must honor the proxy so if there are a ton of methods that's more an issue of the service definition. Fortunately, the generated stubs are just that - stubs to call, unless you are talking thousands of methods I can't see the non-used
methods impacting the size to any level of significance that I'd be concerned with factoring them out. If you control the service, segregate the interfaces better so you have a smaller footprint. If you don't control the service, consider proxying the service
from the web tier and exposing a facade.
3. My most common approach is to have a shared set of models, either via a Silverlight DLL (you can reference those from the .NET framework if they are simple models) or linked files (i.e. same models in Silverlight and server, but linked files so one change
updates everything) and then in the WCF service client definition, check the box to reuse types so it maps to your model, rather than a generated proxy model.
I agree about the sample quickstart and am working on it. The issue that mentions WCF RIA I think will be best addresesd not by modifying the framework but by showing an example.