As Joeqwerty already noted, you're approaching this with an inadequate fundamental understanding, combined with vaguely-defined goals. You are setting yourself up for failure, downtime, and security holes. Rather than just answering your questions as asked I'm going to indulge in a little "vLAN 101" tutorial which might be a bit more useful for you.
You seem to have a few fundamental misconceptions about vLAN segmentation and how it fits into network architecture, so let's roll ALLLLLLL the way back to the beginning for a minute:
From a network architecture level you can take the very simplistic view that a vLAN is nothing more than a separate switch, not connected to any other switch (vLAN).
If you look at vLANs in this way it becomes relatively clear how to use them: When you don't want machines in Group A to be able to talk to machines in Group B you put them in separate vLANs, and force them to traverse a router (ideally one with firewall functionality) to talk to each other.
Under nearly all circumstances it's better (and easier) to do this by also putting the machines in different IP networks (subnets) -- Machines within a vLAN are in the same subnet, and can chat amongst themselves as much as they want, but if they want to talk to someone outside their vLAN it's also going to be outside their subnet, so they get handed off to their default gateway, which can handle the security concern of who can talk to whom under what circumstances.
So vLAN architecture in 11 easy steps:
Figure out which machines form logical groups. These are your vLANs
In a very simple environment this could be Web Servers and Database Servers.
In more complex environments you may have lots of groups, and you may combine multiple groups in a single vLAN -- This is an architecture decision you have to make.
Figure out an addressing scheme that suits your vLANs.
If you're supremely lucky every vLAN will fit into a /24 and you'll be able to build a topology based around that. If you aren't that lucky figure out which vLANs need bigger (or smaller) blocks.
Draw what you have done so far on paper.
Figure out which vLANs need to talk to each other.
What ports/services should be open between vLANs/Networks?
What other conditions need to exist for your environment to function?
Draw what you came up with on paper. Make sure it's sane, then convert it into firewall/router policy.
Draft a firewall/router configuration. Ideally play with it in a test environment.
Draw your switch on paper and map which ports will go to which vLANs.
It's helpful to physically group connections so that they're in the same logical vLAN,
but this isn't strictly necessary.
Turn your switch drawing into a switch configuration. Ideally play with it in a test environment.
Clean up your drawings on paper. The logical drawing should look somewhat like this:
(The image has been shrunk to obscure stuff you don't need to read)
Get someone else to look at your design.
You can ask on Server Fault, but it's better if someone familiar with your environment looks at it as they're more likely to catch potential breakage.
Take a weekend and turn your logical design into a physical reality.
(It should go without saying that you should have a rollback plan in case things go horribly wrong, but I'm saying it anyway.)
(If you are VERY good you might be able to skip some of the "Draw it on paper" steps above, but I don't recommend skipping that your first time.)
Re: the two specific questions you asked:
1)How can I segment this network with minimum down time on the devices already on the network?
You can't. Breaking your network into vLANs will require an outage window - you will have to reconfigure your switch, move machines into different logical networks, configure routing, probably move some cables around, etc. etc. etc.
Plan for an outage starting at 5PM Friday and extending over a weekend, ESPECIALLY if this is your first time designing a properly segmented network - you will spend some time debugging things that break.
2)Can I just create Vlans and leave all these Vlans in the same laye 3 network so that they can go out of the network (I am not not concerned about Vlan routing) or I have to create subnets which means reconfiguring the existing devices (something I do not want)
Can you? Yes.
Will it buy you anything in terms of security? Not really.
Will it make the entire project 10 times harder? Absolutely.
Should you design a network this way? NO.
1) Depends on your security requirements. If your requirements are that the user PC should only be able to communicate with servers/printers, and not between PCs, then yes, you should have ACLs on the Interface VLAN to block traffic as desired. What is the most secure - well blocking everything but what is really needed is the most secure.
2) To do this you simply implement ACLs and apply the ACLs to the Interface VLAN. Since you're trying to allow PCs to Servers/Printers, your ACLs should be simple... something along the lines of:
assuming your subnets are all 10.0.0.0 and your Servers/Printers are in 10.1.1.0/24:
permit ip 10.0.0.0 0.255.255.255 10.1.1.0 0.0.0.255
deny ip any any log
That is obviously a simple version, you'll need to tweak from there to obtain the exact result desired. With this example, you can apply that to all your PC VLAN Interfaces as it is written in a generic way that will work for all your VLANs.
You can find another example of this in another question which I answered last week: Keep router interfaces isolated
Best Answer
Of course you can do that, but it is not the recommended way.
VLANs use software to emulate separate physical LANs. Each VLAN is thus a separate broadcast domain and a separate network.
As you have identified, routing between these VLANs would be difficult, because they are the same subnet. If the addresses are all different it is possible to route traffic using a very large number of rules which don't correspond to the actual subnet configuration and will confuse anyone who inherits this from you. However, it is completely permissible to use the same RFC1918 subnets on different physical networks. You could likely even make all the addresses the same.
The other constraint to bear in mind, and possibly the more relevant one, is that if any of these hosts have to connect to anything at all, routing them to that network will also be difficult. You would have to use NAT almost for sure, and set up NAT rules such that each of these VLANs has a separate outside address. If this configuration doesn't confuse the host OS, it will certainly confuse any administrator trying to work on it.
There are many, many, many RFC1918 addresses available, and there is rarely a real need to conserve addresses in this way. In the extremely unlikely case you are out of them, you can even use the RFC6598 address range
100.64.0.0/10(which is designated as a private range for carrier-grade NAT, and though this is not its intended use, if you're large enough to use up an entire /8, /16, and /12 besides, you could likely make an argument that you are effectively the ISP for these devices).