As with other code style issues, this is subjective and hard to make good universal claims. IEquatable had far fewer members and doesn't muddy readability as much as IEnumerable, for instance, but specifically for IEnumerable I would usually recommend against implementing it at all and instead expose a property. Unless, that is, you're actually implementing a collection type, in which case, isn't the interface a "real" part of your business logic?
#region is a tool. Like many, it can be abused and the code made less readable, but when used properly (and sparingly) it can help readability. One place it can certainly be useful is hiding boilerplate code, and a lot of times implementations of framework interfaces (like IEquatable or IEnumerable) certainly count as boilerplate. But I think that's not a good criterion for "when should I use #region" because a better solution for boilerplate is eliminating it, not hiding it.
You can't eliminate all boilerplate, that's the way it is, but before hiding a piece of boilerplate code with a #region, ask yourself if you actually need this implemented here. Do you need to implement IEnumerable, or does it make more sense to simply expose your inner collection as an IEnumerable property? Do you really need to implement IEquatable on the type itself, or do can you create a separate IEqualityComparer<MyType> implementation?
