How much pre-hashing a password increase security against brute force attack? I am wondering how much hashing a password used as key for a symmetric key algorithm helps preventing brute force attack on crypted text. 

Let's assume I want to crypt text A using key B using AES-256. I expect user to input not secure keys, such as: ['apple', '22march', 'newyork']. 
So I hash these keys with PBKDF2 using many iterations, and I got the key B. That is long and fixed length key I will use for crypting the text with AES.

AES(TEXT, PBKDF2(KEY))


Would this help preventing brute force attacks?

The attackers should also hash each input (for example from a dictionary, where they'll match 'apple') to get the key B for trying decrypting the text A using AES? Or alternatively, they should trying brute forcing directly the AES crypted text, but the keys are always output from PBKDF2 and so they are really difficult to be cracked.
Would this help preventing brute force attacks?


It would slow down an attacker and prevent them from trying as many password guesses. E.g. if you used 1000 rounds like in RFC 2898, you would reduce the number of guesses by a factor of 1000.

Assuming you count dictionary attacks under brute force attacks, such attacks would definitely not be completely prevented. Simplest passwords like your example of 'apple' could be cracked regardless of which (practical) number you choose for iterations. You can't make the work factor large enough that the attacker can't still make hundreds or thousands of guesses in a feasible time, or you can't yourself use it.

But yes, your use of PBKDF2 makes sense and is essentially the purpose of having it in a key generation context. It's just that there is no way to make as simple passwords as 'apple' secure under any circumstances. (At least unless there's another authentication factor.)