Try using the following (a backslash followed by four hexadecimal digits that correspond to the Unicode scalar value of the character U+00AE):

feature ss01 {
    featureNames {
        name "\00AE";
    };
   [...]
} ss01;

I was under the impression that these names can only contain ASCII characters.

The stylistic names may be any encoding supported by the name table, which goes way beyond ASCII. See:
http://www.microsoft.com/typography/otspec/features_pt.htm#ssxx

The feature file supports only ASCII entry for name string values. Non-ascii characters must be represented by the character code in hexadecimal. See the feature file spec section '9.e name table'. This is because name table strings may be specified in many different encodings, and it is not necessarily possible to convert from a given text encoding in the feature file to the desired name string encoding. The simplest approach is to support only the most basic text encoding, and make the user responsible for anything more complex.

Well that was fast! thank you all for responding.

I have tried to escape the characters as shown below:

        featureNames {
            name "Superscript \00AE"; # Windows English
            name 1 0 0 "Superscript \00AE"; # Mac English
            name 3 1 0x040c "\00AE \00E0 l\2019exposant"; # Windows French
            name 1 0 1 "\00AE \00E0 l\2019exposant"; # Mac French
        };

This yields a "Bad string" error tho. Any idea?

Note that similar strings without escapes return no error.

My guess is that the first and third "name" strings are okay, because they refer to Unicode strings. Please try with only those lines. The second and fourth lines are referencing non-Unicode encodings, which are byte-based. You'll need to specify only two hexadecimal digits after the backslash, for the characters that correspond to U+00AE, U+00E0, and U+2019.

The problem is that the two name strings for the Mac platform are using 4 digit hex values. For the Mac platform, Roman script, the encoding values are 1 byte values, and must be represented as 2 digit hexadecimal values, e.g "\AE" rather than "\00AE". If you take out the leasing zeroes for those two strings, I think it will work.

The Macintosh Roman equivalents of U+00AE, U+00E0, and U+2019 are 0xA8, ("\A8"), 0x88 ("\88"), and 0xD5 ("\D5"). Wikipedia's Mac OS Roman page may be helpful.

It works and passes makeotf, thanks Ken, Read. Cheers.

Our pleasure. ☺