I assuming you are using QGIS and that error is what you are getting when it is using GDAL's FileGDB API internally. How do I know this? I made a mistake and forgot to remove the \ from the table name when in the root :)
To answer your question, sadly, there are several EPSG projections that are not properly handled by ESRI's Open FileGDB API.
In order to create the API separate from the rest of the ESRI stack, ESRI took out the projection engine that is used by the rest of ArcGIS. Instead, they implemented a simple version of it. Sadly, sometimes the outputs values that may not be compatible with the rest of ArcGIS. In fact, I have some FeatureClasses that were exported with the FileGDB API which open fine in ArcGIS Explorer (which also uses the FileGDB API), but will refuse to open in ArcCatalog.
There are some options in ogr2ogr that would allow to force a specific SpatialReference (as specified by the command line), but those options are not completely honored by the GDAL FileGDB driver just yet. In theory, that would allow you to circumvent this issue.
The only thing I can recommend to work around this issue is to edit GDAL's database of projections (those CSVs in the GDAL_DATA folder) for that particular spatial reference to match the string that the ESRI stack wants. Not for the faint of heart and definitely not 100% guaranteed that it will work.
Until somebody decides to extend the voodoo in the morphToESRI method from GDAL to handle this specific case, it will not work. If you really want this handled I would try submitting a request in the GDAL Bug tracker. If we get enough of these requests one of us will break down and tackle this lingering zombie issue.
Sorry about that.
Update 1:
Yeah, that did not work. You are going to need to export using a different projection or even a Null projection.
The ideal solution would be for ESRI to extend the FileGDB API so you could create one of their projections objects by only specifying an EPSG SRID, then I wouldn't have to resort to the Voodoo and just point to an "official" SRID. That way we would have two ways of supporting projections and one would be a sane interoperable way.