Spaces inserted by a cube wizard into [Pascal Cased] RDBMS and entity names are already taken care of - by default SSAS Entity Framework Provider uses AddSpacesToCamelCasingWordsConvention, which automatically adds spaces to all PascalCased names within entities when it generates MDX.
We also ship PreserveSpecifiedNameConvention in case if you use exactly the same naming conventions for both your cube and your entities and RDBMS data source.
You can switch a naming convention by assigning a new naming convention to Mdx.NamingConvention static property (e.g. Mdx.NamingConvention = new PreserveSpecifiedNameConvention()). If you use your own naming convention, you can implement our IMdxNamingConvention simple interface and assign your implementation to Mdx.NamingConvention.
If your cube has names that mismatch the names in its relational data source tables on a case by case basis, rather than by convention, than most likely the cube loads data from tables indirectly, using views. In such a case review cube data sources and generate your entities using the same views.
You can rename, split or merge tables or columns, add calculated columns by creating an appropriate view in the source relational database (either transactional replica or relational data warehouse, whatever your cube uses as its data source).
Entity Framework tools can generate entities from views too.
Even if you are not given DDL access to your original relational source database, but you have a 'create database' access, you can create a new relational database for your views (with no data) yourself and point those views to your original source database.
The biggest trouble comes when you remap names and data structures in SSAS data source views (DSV). In that case we recommend to move all re-mapping SQL out from DSV-s into regular views. Re-mapping SQL in DSV-s is a generally discouraged practice. But you have other solutions for this problem as well.
All standard mapping approaches from Microsoft ADO.NET Entity Framework are still available when working with SSAS Entity Framework Provider: you can use Entity Framework attributes, XML and fluent mapping API.
You do not have to generate your entities from a cube relational data source either - you can create your entities using Entity Framework Code First, and than generate database schema from your entity model.
Or you can create entities and properties that match DB names completely by hand.
Regardless how you do it, if SSAS Entity Framework maps your entity and property names into correct dimension, attribute and measure names when it generates MDX, it all will work. Just do not forget to mark your entities that contain cube measures with [MeasureGroup] attribute.
If you start a new project or create new entities, we recommend to start with .NET classes or entity models and automatically create a relational DB schema and then a cube definition (top-down) from them, rather than doing it the other way around.
Entity Framework supports database creation based on EF model, and SSAS provides tools to generate a cube definition from an existing relational database.