I'd say that explorer does the copying to the destination files itself, so there's no way to directly write the destination files. This makes sense, because the names of the source files can only come from the application that copied the data to the clipboard, which need not be explorer. OTOH the names of the destination files may actually differ, because files of the same name could already exist in the destination folder, and only explorer can create the modified names for the destination files (like by prepending "Copy of " or by appending " (2)" to the base file name).
You will need to provide the clipboard format for the Windows Explorer so that it can paste the files. The documentation of standard clipboard formats suggests that CF_HDROP is the right one. With this clipboard format you would provide a list of source file names, but the files do need to exist of course, so you will need to save them to disc.
You could try to make the process as light-weight as possible, though. Usually when a user copies data to the clipboard it is put there immediately, whether or not it will be used for a paste operation. For your application that would mean that you would need to create the files and put the list of file names into the clipboard, every time. However, Windows does support a mode called Delayed Rendering, which is used exactly for such cases. Basically you put only an empty stub of the data onto the clipboard, and only when another application tries to access the data it will be requested from your app. So you could implement this in a way that only when the user tries to paste the files into explorer you would save them to disc and return the list of file names.