I think that it would be possible to make an Integrated Redstone Circuit designing and manufacturing machine. This suggestion will cover how the ICs produced by such a machine would function.

As the logic circuits involved would be designed on a grid of finite size, symbols placed onto this grid will be referred to as 'tiles'

Each IC will be made up of two types of tiles: wires and gates. Each tile will have a coordinate that is logged in the tile entity data.

The wires in the IC would have to work with iterators (henceforth referred to as 'tokens').

As for the gates, they would have to be objects in order to be able to store information about which inputs are active, and to be able to know what to do with the outputs.

Each redstone tick, the IC would work in two distinct stages

Stage 1: Gates

All gates are loaded into memory as long as the IC has at least one token or gate active.

The gate has a main method that is called when the block finds the gate in the array that was modified last redstone tick by tokens.

The gate reads variables that correspond to it's inputs, and decides what to do with them based on it's gate type.

Then, it initializes a token on the location of the wire that leads to the output.

Stage 2: Tokens

Each token would have to have at least three variables. One for if it is on or off, one for the current X coordinate on the virtual grid that composes the IC, and one for the Y coordinate.

As a token goes through the different tiles, it would call different methods for each tile that it finds. For wires, the methods would be as simple as changing one of its own coordinate variables to match that of the next wire in the sequence.

If it reaches a wire with more than one direction that it can go, it would initialize a new token for one of the directions log a new token in the first available slot of the array of the block's token array, setting one of the coordinate variables to the proper value to send the other token on it's way down one of the wires. It then sets one of it's own coordinate variables to the proper value to move on to the next tile in the line.

When it reaches a gate, it would delete its entry in the token array, and then signal the gate active by entering the gate's pointer into the block's gate array. It also changes the value of the input of the gate that it reaches to powered, with whatever redstone strength it is when it reaches it.

Once the array for the tokens is emptied out, then the redstone tick logic for that block is ended.

Data

The block's tile entity may be a bit of a mess. Seeing as all of this is going to be in NBT format, it would have to have a Byte Array to signal what each tile is, and a second Byte Array for rotation. (An Int Array would be able to store them both, but this solution has the computer loading in 16 bits per tile, and not 32. I think that this translates into a reduction in lag. If I am wrong, please let me know.)

If there are any active gates or tokens when the block is unloaded, these are stored in a compound tag. This lists:
For tokens, the location and strength of the signal.
For gates, the signal strength of all inputs.

Then, once you have stored the data, loading it into memory might cause some lag. Thus, it would be prudent to limit the size of the grid involved.

Caveat

We have to remember that the more complex the logic is (that is, the more tokens and gates you have active at one time), the more laggy it is going to be. For this reason also, it is prudent to limit the size of the grid involved.

If I wasn't clear enough, I will do my best to explain better on any part of this.

There would be no point. Any gate that you can make like this is already possible with a small combination of the actual gates. More trouble then its worth.