Even better, your custom memcpy might sometimes result in working code and sometimes be replaced with a call to memcpy[1] and then break. When this happens will depend on the compiler and optimization level and even if you manage to write one that isn't replaced today the next version of GCC might be smart enough to figure it out.
Optimizing to assembly that calls the actual external memcpy implementation should be fine. If the custom memcpy works with NULL, without triggering undefined behavior, then any further optimization which assumes memcpy's NULL semantics would be clearly incorrect (which is not to say some compiler won't do it, but it would be a bug). The bug report you linked is about naming a function "memcpy", which is different - and IMO GCC's behavior was indeed incorrect until the change to disable the problematic functionality with -ffreestanding.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888