I have used EF with SQL Server 2008 & 2005, Pro, Standard and Express. I have not every bothered playing with CE, because for the most part the experience should be the same. But there are a few places where you might run into trouble. One is related to connecting to the database and has nothing to do with EF, meaning that you can experience this with other data access technologies as well. The other has to do with the newSequentialID type which is not supported.

The first of these problems is just an annoyance as you identify the trouble and figure out how to get around it. This is just what Josh Dalcher had to deal with over the weekend as he was trying to build a small EF app using SSCE. He was able to query the db but inserts and updates were not making it to the database and the exception returned was random and not very helpful. Fortunately, he persisted and discovered a blog post that Tim Anderson had written about this problem. Essentially, SQL Server CE's default connection points to the file you originally set it to and in Josh's case the path was relative to the application. When you are debugging the application path is not the same as a deployed application path. Therefore when he was debugging, the app was looking inside of BIN/DEBUG for the database file. gets confused between the target db and a copy that it works with.

Check Josh's blog post ".NET Frustrations" and Tim's post, Where is your SQL Server CE Database?, for more details.

The latter issue is that SQL Server CE's "newSequentialID" datatype is a GUID and EF doesn't support auto-incremented GUIDs. You  can find numerous threads in the MSDN forums about this.

I also happened to come across this blog post that talks about an issue with SQL CE that shows up when you use it with LINQ to SQL and EF. It looks like data type confusing between nText and nVarchar types. You can read more in this blog post which also points to a hot fix for SSCE to correct the problem.