I have a .NET 4 class library that contains an Entity Framework data model and a collection of classes that provide common functionality using those entities. These classes are used across different types of applications. 

So, my question is would it be considered good practice to expose entities contained within the class library to other applications?
['https://Stackoverflow.com/questions/8389278', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/667108/']
If your entities are advanced enough to meet your persistence needs *and* your domain needs (or external application needs) and there is not much or a low-likelihood of "cross-layer pollution", then I say yes it's a good practice. It can also be a good practice in the agile development sense: good-enough-for-now.

Given a longer period of time and if being a purist is more your inclination, then it starts to become a bad practice because you're increasing the coupling, for example, if you start adding attributes to deal with persistence, validation, and serialization.

Some ways to avoid that are to use something like [AutoMapper](https://github.com/AutoMapper/AutoMapper), generated code, or hand-coded facades, service layers, and/or adapters to minimize the effects.
Because entity framework changes whenever the database changes, I don't believe this would provide an adequate API. Instead, I would recommend creating a Data Transfer Object to act as an intermediary between external code and each entity that needs to be accessed. Furthermore, consider creating a Facade class (Service layer) that will mediate between the internals of your library and the external "client." Good article on DTOs: <http://msdn.microsoft.com/en-us/magazine/ee236638.aspx>