Q:

How to design system for n bits?

Say I want to design an n-bit system e.g. 256 bits. Can I generalize a 4-bit ALU which I think I know to 256 bits? These are my diagrams.

A:

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.

A:

Some aspects of a system can be made to use arbitrary data widths, though there are often relationships between different parts of a system.  For example, in most cases the number of words per instruction or instructions per word would vary with the data width.  One likely wouldn't want to try to use four-bit instructions even if one used a four-bit data word (I think the Intel 4004 used mostly 8-bit instructions), nor would one want to use 256-bit instructions if one used a 256-bit data word.  If instructions will be fetched over a separate bus than the data, such issues may not apply as significantly, at least once the data bus is wide enough to hold an entire address.
As Chris Stratton noted, carry propagation speed may be an issue, but it need not be nearly as severe as he suggests, since there are some tricks that can speed carry propagation greatly.  One major trick is to produce what are called "P" and "G" signals.  A "P" signal for a block means that the block's carry output will be set if its carry input is set.  A "G" signal means that the block's carry output will be set whether or not its input is set.  For a single-stage two-input-plus-carry adder, the "P" signal is the "OR" of the data inputs, while the "G" signal is the "AND" of the data inputs.  Two adder blocks H and L of any size may be combined into a larger block by having the "P" signal of the larger block be the (PH and PL), and the "G" signal of the larger block be "GH or (PH and GL)".  Even a 256-bit adder could generate its P and G signals within about 16 gate delays of the input becoming valid; if the carry into the adder is valid by that point, the carry out of the adder will become valid two gate delays later, and the P and G signals may be used to compute the carry at each individual stage within 16 gate delays.  So even a 256-bit addition may be performed in about 32 gate delays.
If even that would be too slow, one may be able to benefit from a device called a Carry Save Adder.  Basically the idea of a Carry Save Adder is that it takes three arbitrary numbers as input and outputs two numbers whose sum will be the same as the original three.  It's actually very simple--just use a full adder at each bit stage, using the "data" output of each adder to form one number, and the "carry" output, shifted left one bit, to form the other.  Whereas a conventional adder takes somewhat longer to perform computation on larger numbers than on smaller numbers, a carry save adder always performs its computation in about two gate delays, regardless of operand size.  Combining three numbers into two isn't terribly useful by itself, but using two carry-save adders one may combine four numbers into two.  If one were to double-up on the size of one's registers, one could have each register contain two numbers which when added together would yield the "correct" value of the register.  Adding two registers would entail adding four numbers to yield two--an operation which could be performed in four gate propagation times.  Note that this approach would allow for extremely fast computations when registers were used for consecutive additions or subtractions.  If one wanted to perform other operations (e.g. use the registers for array subscripting, or perform boolean masking operations on them) one would need to resolve the actual numerical values of the registers first.

