I understand your situation and it's a bit problematic. The main issue is that the mappings you created state that a datetime value is coming back from the database, not a binary value. This means that the typed entity field mapped onto that table field is stated to be of type DateTime and the binary value can't be converted to DateTime.
So as the entity classes use types for the fields (as it's normal C# code) this won't work: the value is read from the DB, but when you access the field BirthDate through the property the system needs to return a DateTime and that doesn't work of course: the value is a binary value, the cast will fail (it has no other option).
However it's not all misery, there are solutions.
The easiest is this:
create a partial class of the generated CommonEntityBase (in the EntityClasses folder). In the partial class, override the method PostProcessValueToGet(). This is the method that's called right before the value to return from a property read is handed over to the property. So on the code:
var bd = someEntity.BirthDay;
it will end up in that method right before the getter of BirthDay will perform its cast to DateTime and return the value.
In your override you have to check whether the types of the value (in valueToReturn) matches the type in fieldInfoOfFieldToGet.DataType. In the case of BirthDay, fieldInfoOfFieldToGet.DataType will be typeof(DateTime) and valueToReturn will either be null or a binary or a DateTime.
If the types match (no need to know what the value is, the types are enough), do nothing. If the types don't match (in case of the encrypted value is read from the database, so it's a binary value), you have to decide what to return there: a default date, null (the field then has to be made optional in the designer) or leave it as-is and result in an exception.
The method is used by all entities, so you have to implement this once in a general way which should be rather straight forward. It will then make sure no cast exceptions arise due to the type mismatches between encrypted data and the expected real value, it will also not require you to decrypt any data if the user isn't able to: the encrypted data is inside the entity but not decryptable and not exported outside the entity as well. It's transparent as you don't have to anything to make it work with decrypted data: when the user is able to decrypt the data as the key is on the user's system, the values will obviously match the type of the field and nothing is done in your override so it should work normally like any non-encrypted field.
Hope this helps
(edit) if you create custom projections this doesn't work though: the value will then mismatch the end type. So this is only for entities.
Another way to solve this, which involves more work, is by using type converters, one for each .NET type used in the fields. Say you encrypt some DateTime fields and string fields. you then create two type converters, one for DateTime and one for string.
they convert from / to the same type. So the DateTime type converter converts from / to DateTime, the string type converter converts from / to string. Both are effectively a no-op if the passed in value is null or a string. However, if the passed in value is a binary, they know the value is encrypted and then you have to decide what to do: return null (which will result in the default value being used) or a default value, e.g. string.Empty for the string values.
This is also transparent: if the user can decrypt the values, the values read from the DB are in the real types, nothing is done. When the user can't decrypt the values, the values are binary and converted right after the datareader to the value you convert to in your type converter. This also works in custom projections as the runtime will try to re-use the type converter of the fields the actual outer projection is projecting from.
Type converters are really easy to create. the only downside to this approach is that you have to assign the type converters to each mapped field that's encrypted, which is perhaps a bit of work as the designer won't do that for you as the types match so it won't automatically assign the type converter. You also have to know which fields are encrypted up front and forgetting one will cause an error. You could ofcourse implement both approaches.
If you need help with a type converter, please let us know.