How to design system for n bits?
Not really.

You can for some purposes set up an array of 4-bit computation units to act on a 256 bit word, but many operations have interdependence between the bits, for example the carry in addition and subtraction.  Within a stage, special look-ahead carry generation is used to make sure that the more significant bits get their carry input in time to produce their output at the same time the less significant bits do.

But you won't be able to get that between stages, especially not between an array of 64 such stages.  In simple terms, each stage will delay the carry by one clock period, so computation of your highest order stage could begin only 63 clocks after computation of the lowest order one, when the necessary carry input finally becomes available.

It is possible to build a system which compensates for this, by using registers to delay the higher order inputs by the necessary clock cycles until the carry inputs become available, and other registers to delay the lower order outputs until the corresponding high order outputs become available. This is called pipelining - you can have a system which requires 64 clocks to produce an answer (latency).  But it can have an answer to a distinct problem in-progress at each stage of the pipeline, so one answer gets produced every clock cycle (throughput).  

This is commonly done at more more reasonable lengths in general purpose processors, but there is a big price to pay.   What if a subsequent instruction relies on the result of a computation that is recent enough that it is still percolating through the pipeline when the dependent computation enters the pipeline?   Real processors have extra "bypass paths" added to allow feeding back recently previous results faster than you would get them out of the bottom of the pipeline and back into the top.  This helps avoid pipeline stalls, but only to a degree.

There's another problem too: what happens with a conditional branch instruction?  Do you keep filling the pipeline with potentially needed computations assuming the branch is taken?  Assuming it is not taken?  Have a sort of dual-core processor the tries both possibilities?   If you try both, what if you hit a second branch, are you going to try both possibilities for that too?

In short, you are asking about what is for most purposes an unreasonably extreme example of a technique which does actually get used at more reasonable scales, subject to some fairly severe costs.

And there is a major class of exception where pipelines this long would not be inconceivable.  That is computation engines which do the same thing to a lot of data in a highly repeatable way: DSP chips, some types of constructs in FPGAs and ASICs, and quite possibly GPUs as well.  If the program flow is a simple loop, you need to operate on a lot of data, and its okay for the results to be delayed by many clocks, then quite long pipelines can be a fairly reasonable approach.