I'll take a stab at addressing some of this, but I think I'll need Microsoft to weigh in and address part of it.
By "Azure" I assume you're talking specifically about Sql Data Services (SDS, formerly known as SSDS), a service built on top of Azure. You could also be talking about the Storage part of Azure, I suppose. I believe my answers could apply equally well to both, since both expose a very similar REST interface.
You would not use SDS as a layer that exposes your conceptual model from EF. SDS itself exposes a RESTful interface, similar to what ADO.NET Data Services does (Astoria) for the entity framework. That RESTful interface is the interface into your data, and uses the AtomPub protocol in the same way that Astoria does. The technology underlying SDS is SQL Server 2008, but you don't ever create tables, views, stored procedures etc. in SDS in the same way you would if you were interacting with SQL Server 2008 directly. Instead you simply create entities within containers in SDS using the REST interface, and it handles storing them somewhere in the cloud. Partioning in this case is handled at the container level, so all entities stored in a particular container end up in the same partition. That means that you have to make up-front decisions about partioning as part of defining your data model.
So you would not create a conceptual model in EF and then somehow expose that via SDS. That's what ADO.NET Data Services would be used for.
The other part of your question is probably what you (and I) really want to know. Will you be able to use SDS as the underlying data provider for an EDM, and then use the MSL to map conceptual objects in the CSDL to SDS URIs using the SSDL? I'm not positive, but I suspect the answer is going to be "no". I think that the intended paradigm here is that you use ADO.NET Data Services Client (the Astoria client) classes for your business objects, and under the covers ADO.NET Data Services is handling the communication with SDS in the same (or very similar) way it handles communicating with ADO.NET Data Services on a traditional server.
I believe the argument here might be that SDS takes away so many of the practical details of dealing with scalable databases that you can think of your "schema" in SDS as being closer to the conceptual model than you would normally have when creating an RDBMS schema directly. I'm not positive that's the argument they would make, but I think it could be.
And to extend that concept, your goal when using SDS is to design your "schema" to be implicitly scalable. I believe that your data model has to be exposed all the way up to the business layer for you to be able to create an application that is itself truly scalable. For example, the application has to know something about how you've chosen to partition your data model using the SDS containers in order to write parallelized queries using first-class parallelization structures in the language (that will be forthcoming soon; I believe right now they're implemented as extension methods).
Without the ability to leverage parallelization in large-scale applications, you lose the benefit associated with leveraging Azure and its ability to spread workload (and storage) over many instances of your "application" (role instances) in the cloud. On a single machine, implementing that sort of parallelization might mean firing off multiple worker threads that each query a different partition in your data model and then coalescing the results when they all return. When using Azure, that might mean having multiple instances of a background worker role that each handle querying a different partition in your data model. The end result is that you get much better performance than if you either tried to a) store all of your objects in a single container/partition or b) ran your query or queries on a single thread/role that had to query across all of your data, whether partitioned or not.
I think that if you were to hide that partitioning information using an abstract data model in the same way that EF allows you to use CSDL to hide database implementation details via its mapping to SSDL then you would no longer be able to leverage those parallelization features.
I'm not sure I said that right, and I'm not sure I'm actually right at all. I'm somewhat thinking out loud and trying to remember what I learned at the PDC last week while I'm typing this. Hopefully someone from Microsoft will contribute to this thread as well.