The C167 is a 16-bit micro with a clock speed of 20MHz. Any recent microcontroller should reproduce its functionality just fine.
You first need to analyze the function of the C167 in the system, not just as a processor. Sure, a NIOS processor could replace your microcontroller core, but what about the peripherals used on the board? Is heavy use made of ADCs, DACs, and other microcontroller features that have some sort of 'analog' nature.
Its very easy to interface ADCs and DACs to FPGAs, and you get the extra freedom to implement hardware-based control of these devices. However, if your design is cost-sensitive, then look at the microcontrollers on the market, eg., the Philips/NXP LPC series 32-bit ARM cores. These microcontrollers have ADCs, DACs, timers etc, and for less than $1 in some cases.
As for code porting, it depends on how well the original code was abstracted from the hardware. For example, I use the uC/OS-II on DSPs and NIOS processors, and the code is easily ported between the two. If however, the code for your C167 uses a lot of compiler-specific extensions, then you will need to abstract those interfaces. What you can do is move the C167 compiler specific code into function calls in a separate C-file, eg. hw_access.c, and rebuild your code to confirm it operates correctly. Then rebuild the code using gcc, replacing the hardware access code with stubs, eg. hw_access_stubs.c. Your code would compile, but hardware accesses would be 'faked out' by the stubs code. This gets a little trickier with interrupt handling. But you get the idea.
If you are considering using something like uC/OS-II (or uC/OS-III) in your new design, then you could port your existing code to this OS on the C167, and then port the code to NIOS, or perhaps one of the microcontroller boards that comes with the uC/OS-III books.
Cheers,
Dave