In principle I think something like this should go in.  Since it is a Message subclass, I'd like it to follow the current Message API whether or not it is located in the email package.  __str__ and as_string have the right default for line length (no folding).  The current default for line endings is \n, and I think the class should stick with that.  You can't use __str__ or as_string to generate what you send on the wire if you are supporting binary data.

I am planning additions to the email API that will make integrating this class and adjusting the generated line endings easier.  For the latter (assuming the email-sig approves) I plan a __bytes__ method that will generate "wire format", which would include using \r\n line endings and should be just what you need.

The current email package does not support the binary content transfer encoding, only 8bit.  Support for the binary CTE is another planned addition for 3.3, and I think it can be prioritized ahead of most other features, given that this code needs it.

So, you might want to wait until the email pieces are in place, and possibly even help me develop them :)