You can use the TRIVIAL method, as shown by fkraiem. This generates uniform results, but does use a lot of RNG calls, as Ilmari pointed out. In practice this may be a non-issue or may be very important (e.g. getting results from /dev/random may stall; getting good entropy on an isolated embedded device may be difficult).
You can optimize this slightly by generating the inner $n-2$ bits and setting the first and last bits to one, which saves no time in any sane primality test, but uses less randomness on average.
There are some faster methods, such as Fouque and Tibouchi (2011 and 2014). These no longer generate with perfect uniformity, but bound it to an extremely small value. They use many fewer random bits.
I believe what Begueradj was getting at with his "+2" step is the PRIMEINC method, which is basically saying "generate a random value $t$, if $t$ isn't prime, then return ${\rm nextprime}(t)$." This is fast but very non-uniform. While nobody knows how to exploit this for the sizes of numbers we're talking about, it seems dubious to knowingly use a method which returns some numbers many orders of magnitude more often than others.
There are also the methods of Maurer and Shawe-Taylor. The latter is described in FIPS 186-4. Menezes et al. describes them both. These build up provable random primes -- no primality testing needed (though if you are implementing this I strongly recommend doing tests and assertions throughout the code -- including perhaps having it output a primality proof which is verified by other code). (Added 2017:) As mentioned in a comment, a GMP implementation of Shawe-Taylor is very similar in speed to the trivial method. Maurer's algorithm is perhaps 1.5x slower (it works harder to maintain diversity vs. S-T).
For primality testing, see FIPS 186-4 for some detailed info including detailed algorithms and numbers of tests recommended for given security levels. In practice, random composites of this size are highly unlikely to pass even a single Miller-Rabin test, hence you will almost certainly be doing only 1 test per composite, followed by the full suite for your probable prime.
Details of test performance optimization can be seen in something like this answer. The goal is to reject composites as fast as possible.
As fkraiem points out, primality testing is far, far easier than factoring. Some example times for 2048-bit (616 digit) numbers:
- a single M-R test takes ~2 milliseconds
- random primes using BPSW plus some extra M-R tests takes 0.25 seconds on a Macbook.
- random constructive proven primes takes 0.25 - 1 second.
- random BPSW prime plus generic proof (APR-CL or ECPP) in about 30 seconds
The last (random prime followed by proof) is almost never used, except perhaps for the smaller DSA primes (proving a 160-bit or 256-bit number is very fast). But this shows even for this size it can be done in a reasonable time.