There aren’t any hard rules that I know of, but the common practice in C# would be to put your standard implementations into the same package as the interface. For example, IList and List both live in the system.collections.generic namespace.

If the implementation is sufficiently specialised you might want to put it into a sub-package. The main thing though, especially if your framework has a significant number of packages, is to be consistent.

Try to think about it from the point of view of someone who’s going to use your framework: ideally you want them to be able to discover your classes without having to refer to the documentation.

Separate Assembly?

The answer here depends upon how you intend the examples to be used.
If they are templates that can then be directly reused by others within the framework, include them in the assembly.
If the intent is a copy and paste type exercise, put them in a separate assembly.

Namespace

Here, I would suggest that you use a separate namespace regardless of how the examples are to be used. In general, you would expect the users of your framework to have their own namespaces surrounding their work and integrating with your framework’s namespace. It will make the example more valid by following that model yourself.
Likewise, reverse that advice if you really intend them to extend your framework’s namespace.

Your example implementations should be in your unit test assembly (you really should have one, it is the easiest way to test any kind of general library you are building). Examples of using a library will often serve well as some kind of test, and vice versa. Since your unit test assembly is linked against your testing framework (which you normally don’t want to deploy), it must be a separate assembly.

Concerning namespace I totally agree to GlenH7.