This works because, from the parser's point of view, an Objective-C string is an @ token followed by a C-string token. In fact, you are not concatenating C strings with Objective-C strings at all. The preprocessor is concatenating two C strings then the parser is constructing an Objective-C string from an @ and a C string.
I like the idea of __fmt__(), but it will be tricky to implement. The string concatenation happens in the preprocessor, but the type information isn't available until much layer. This is why you can't do things like #if sizeof(int) == 4 in preprocessor macros, even though everyone wants to. With clang, in normal operation, the preprocessor isn't quite such a separate step as in a traditional C compiler (where it is an entirely separate program), so this might be possible.
If you're happy with adding incompatible language extensions, maybe you should consider, as an alternative, adding a new type specifier that's understood in format strings to functions marked with the printf attribute. That way, you'd do something like this:
NSLog(@"Hello, %!! This is your user id: %!", username, userID);
The printf format string checker in clang already has code to see what the format string for the specified type should be, so you can just have it replace the ! with the correct value in the string.
Note that this has some problems, however. If the argument is an int, for example, would you insert %x or %d? This applies even with the original __fmt__() pseudo-macro idea. There is not an injective mapping from types to format strings. This is especially true if you consider modifiers. With __fmt__(), I'm not sure how you would specify whether to show the sign, the precision, or the width, for example.
-- Sent from my brain