There are a number of issues with this.
The biggest is the delay - the delay of a combinatorial path through the FPGA is hard to constrain and is subject to large process/voltage/temperature variation. So while this can be done, it is very difficult to understand how the clock/data phase relationship on your output will relate to those on your input.
This is particularly true if you do what you are proposing, and run the clock through a BUFG - the BUFG will have very different delay characteristics than the data. In fact, since you are not using this clock as a "clock" there is no point in using a BUFG.
It is worth noting that the delay through the FPGA is going to be quite large - certainly more than 3, maybe even more than 5ns (or more depending on the I/O standards you are using).
As others have pointed out - this is not what an FPGA is designed to do - it does not have particularly good timing characteristics when used this way. If the "interface" is to be forwarded through the FPGA, (and you can afford some latency), then you should consider "terminating and regenerating" the interface; using the input clock to capture the incoming data, pipeline the data through the FPGA, and then regenerate the forwarded clock and forwarded data with a phase relationship that makes sense for the receiving device.
Avrum
