When it's used as it's intended to, the nonce usually begins at a certain point and increments from there. This can restart every second, since there is a second-specific timestamp in the block, but modern ASICs can do far more than 2^32 hashes per second, so it seems reasonable that nonces should be distributed fairly evenly.

may a miner force a mined block to have a specific nonce? (if his hashrate allows him to)

Yes. He'd do this by having his nonce entirely within the transactions (the coinbase transaction, a.k.a. block reward, is a perfect place for this); by changing any transaction, the Merkle root in the block header will change. The usual mining loop, in pseudocode, only takes two SHA256 hashes per attempt.

  If you only include the coinbase transaction, this will add (at least; I'm unsure if it'd have to fill out 1 to be an even number, as it does for 3) two SHA256 hashes per attempt, meaning you'd be (at least) twice as slow as normal. I'm also unsure whether existing ASICs are capable of doing this different calculation.

The number of hashes would grow with (proportional to the logarithm of) the number of transactions in the block. If you include just 2 more transactions (so I can mirror the example at the wiki). You'd have to do 7 double-hashes to build the Merkle root, for a total of 16 SHA256 hashes (1/8th your normal speed).

When it's used as it's intended to, the nonce usually begins at a certain point and increments from there. This can restart every second, since there is a second-specific timestamp in the block, but modern ASICs can do far more than 2^32 hashes per second, so it seems reasonable that nonces should be distributed fairly evenly.

may a miner force a mined block to have a specific nonce? (if his hashrate allows him to)

Yes. He'd do this by fixing his block header's nonce and changing transactions instead (the coinbase transaction, a.k.a. block reward, is a perfect place for this); by changing any transaction, the Merkle root in the block header will change. 

The usual mining loop only takes two SHA256 hashes per attempt. If you only include the coinbase transaction in your block, this will add (at least; I'm unsure if it'd have to fill out 1 to be an even number, as it does for 3) two SHA256 hashes per attempt, meaning you'd be (at least) twice as slow as normal. I'm also unsure whether existing ASICs are capable of doing this different calculation.

The number of hashes would grow with (proportional to the logarithm of) the number of transactions in the block. If you include just 2 more transactions (so I can mirror the example at the wiki). You'd have to do 3 double-hashes to rebuild the Merkle root (there are 7 double-hashes total, but some of them could be reused) before your double-hash of the block header, for a total of 8 SHA256 hashes (1/4th your normal speed).

When it's used as it's intended to, the nonce usually begins at a certain point and increments from there. This can restart every second, since there is a second-specific timestamp in the block, but modern ASICs can do far more than 2^32 hashes per second, so it seems reasonable that nonces should be distributed fairly evenly.

may a miner force a mined block to have a specific nonce? (if his hashrate allows him to)

Yes. He'd do this by having his nonce entirely within the transactions (the coinbase transaction, a.k.a. block reward, is a perfect place for this); by changing any transaction, the Merkle root in the block header will change. The usual mining loop, in pseudocode, only takes two SHA256 hashes per attempt.

If you only include the coinbase transaction, this will add (at least; I'm unsure if it'd have to fill out 1 to be an even number, as it does for 3) two SHA256 hashes per attempt, meaning you'd be (at least) twice as slow as your competition. I'm also unsure whether existing ASICs are capable of doing this different calculation.

The number of hashes would grow with the number of transactions in the block, e.g. if you include just 2 more transactions (so I can mirror the example at the wiki). You'd have to do 7 double-hashes to build the Merkle root, for a total of 16 SHA256 hashes.

When it's used as it's intended to, the nonce usually begins at a certain point and increments from there. This can restart every second, since there is a second-specific timestamp in the block, but modern ASICs can do far more than 2^32 hashes per second, so it seems reasonable that nonces should be distributed fairly evenly.

may a miner force a mined block to have a specific nonce? (if his hashrate allows him to)

Yes. He'd do this by having his nonce entirely within the transactions (the coinbase transaction, a.k.a. block reward, is a perfect place for this); by changing any transaction, the Merkle root in the block header will change. The usual mining loop, in pseudocode, only takes two SHA256 hashes per attempt.

If you only include the coinbase transaction, this will add (at least; I'm unsure if it'd have to fill out 1 to be an even number, as it does for 3) two SHA256 hashes per attempt, meaning you'd be (at least) twice as slow as normal. I'm also unsure whether existing ASICs are capable of doing this different calculation.

The number of hashes would grow with (proportional to the logarithm of) the number of transactions in the block. If you include just 2 more transactions (so I can mirror the example at the wiki). You'd have to do 7 double-hashes to build the Merkle root, for a total of 16 SHA256 hashes (1/8th your normal speed).