To be honest, I think you're asking for something that can't really be done.
I'm sure there are technologies that could facilitate the kind of dynamically bound data model you're after (I've seen something similar written in Visual Basic 6.0 - but that solution hit issues with performance on data access once their data set started to scale up). The difference between LightSwitch and VB 6.0 is that VB 6.0 allowed you to dynamically construct your screens and modify data binding in run-time - and this was facilitated by the fact that VB6.0 apps are late bound - they have a heritage of pre-.net VB running as a run-time interpreter. The output of LightSwitch is compiled .Net MSIL - especially on the server side. Even though that code is only compiled down to MSIL, not assembly language or machine code, it's strongly typed and early bound.
LightSwitch performs its data binding at compile time against the service layer by generating code based on T4 Templates that run against the data and screen models in respective .LSML files and extending base classes with additional code-behind/appended JavaScript as needed. Unless you're generating services on the fly I don't see how LightSwitch could possibly bind screens (the easy bit in this scenario) to services that don't exist when you run your application.
You should also note that LightSwitch generally expects the entities in the data model to be strongly typed. Even if you were able to create a service that translated a key-value pair (i.e. dictionary object) entity into something that looked like a strongly typed tabular data set exposed for CRUD operations, the performance on the data access would be completely awful, and without a database optimized for arbitrating foreign keys, unique constraints, table joins, etc... ugh I can't see it ever being anywhere near as performant as a relational database. Some sort of NoSQL database might improve performance, but then you'd need a service that translates LightSwitch LINQ to Entities queries into platform specific map-reduce operations.
I'm not saying that what you're asking for can't be done in any kind of absolute way. If you were to compose your screen data as XML documents that could be written into an XML-typed column in a SQL Server table, that might be workable. For that to work, you'd probably need to include some kind of reference XML schema document (or a foreign key against a table containing such reference XSDs in an XML type) to be able to unwrap your screen documents as needed.
However, I don't think Silverlight would be the best technology for building screens based on those XSDs, or data binding the data storage layer against a service that exposed that sort of XML-centric data model. You might even be able to bake this process into a screen template, but ultimately Silverlight is too strongly typed, and optimized for early binding. HTML Client would make a lot more sense, as you could intercept the create() event when emitting the HTML for the screen, and before_ApplyChanges() screen event to serialize the screen data into XML for transmission over the wire. However, what you'd be doing would effectively replacing pretty much everything that LightSwitch emits except for the CSS.
In my opinion you'd be better off doing this with something like an ASP.NET MVC application as you could build the model around the KVP schema, build view templates that effectively apply an XSLT translation to your XML schema/data to do the heavy lifting you need, and you won't have the extra layers of code (i.e. LightSwitch's plumbing) sitting between your generated screens and dynamic data model. Dynamic (screen) to Dynamic (data) is much simpler and will be more efficient than a solution that looks more like Dynamic (screen) to Strongly Typed (Silverlight screen plumbing) to even More Strongly Typed (Entity service model) to Dynamically Typed (XML storage).
Remember there is a reason that strong typing exists. It performs well. It gets results. If you have a clear set of business requirement that can absolutely only be delivered by dynamic forms and data, look at using a solution architecture that's optimized for that pattern. IMO, LightSwitch (remember - early bound using generated code) is not the architecture you're looking for. waves hands, exerts Jedi mind-control :)
