I organize extension methods using a combination of namespace and class name, and it's similar to the way you describe in the question.
Generally I have some sort of "primary assembly" in my solution that provides the majority of the shared functionality (like extension methods). We'll call this assembly "Framework" for the sake of discussion.
Within the Framework assembly, I try to mimic the namespaces of the things for which I have extension methods. For example, if I'm extending System.Web.HttpApplication, I'd have a "Framework.Web" namespace. Classes like "String" and "Object," being in the "System" namespace, translate to the root "Framework" namespace in that assembly.
Finally, naming goes along the lines you've specified in the question - the type name with "Extensions" as a suffix. This yields a class hierarchy like this:
- Framework (namespace)
- Framework.ObjectExtensions (class)
- Framework.StringExtensions (class)
- Framework.Web (namespace)
- Framework.Web.HttpApplicationExtensions (class)
The benefit is that, from a maintenance perspective, it's really easy later to go find the extension methods for a given type.